Java 尝试使用资源单元测试覆盖率

我想问一下，您是否有任何技术可以用单元测试来覆盖try-with-resource。我用它来打开一些流，eclemma向我展示了我在这个资源块的尝试中发现的分支。我知道在编译之后，这个块显然被翻译成了其他的东西，但这是否意味着如果我使用它，我就不能100%地覆盖emma？ 你有什么技巧来处理这个问题吗？我喜欢100%的保险

---

谢谢

在编写测试用例时，实际上我们应该关注功能，而不是测试覆盖率。如果你想覆盖这些领域，最好使用一些模拟工具，比如覆盖那些尝试领域，简单的答案是否定的

长答覆： 正如这里所描述的：try-with-resource被编译成一组非常复杂的语句，其中一些分支可能不是每个人的代码都可以访问的

截至目前（2014年10月），Jacoco（eclemma）没有为您过滤那些无法访问的分支，但是有一个方法可以做到这一点，但我不知道它是否会或何时会实施

虽然100%的代码覆盖率很好，但这不是一个盲目遵循的好指标。100%的代码覆盖率不会告诉您任何事情，除非您有执行所有代码行的测试。如果覆盖的代码做了错误的事情或做得不够，那么代码仍然可能有bug。 多年来，我在代码区域发现了100%个错误，覆盖了所有的语句，因为虽然我的测试覆盖了所有的语句，但我没有考虑所有的边缘情况，所以我的代码在很少见的场合出现了错误。 此外，如果您的项目足够大，那么这些遗漏的分支几乎不会有什么不同。那么，如果你只有99%的覆盖率呢。

我这样做了：

public class Something implements AutoCloseable {
    private HttpAutomationClient client;

    //methods for connecting, etc

    @Override
    public void close() {
        shutdown();           
    }

    void shutdown() {
        client.shutdown();
    }   
}

public class SomethingTest { 

    //stuff
    @Test
    public autocloseableShutsDownTheClient() {
        final HttpAutomationClient client = mock(HttpAutomationClient.class);
        Something something = null;
        try  (final Something spy = spy(new Something())) {
            something = spy;
            TestHelper.setField(something, "client", client); //sets a field using reflection
        }
        verify(somehing).shutdown();
        verify(client).shutdown();
    }
}

---

我同意你的观点，功能是最重要的，但100%的覆盖率给你带来了其他好处。显然，从质量上看，你可以看出你有百分之几的覆盖率。但是我想说的是，获得代码覆盖率的“场景”比“仅仅覆盖率”更重要。对这个问题投反对票的人能告诉我他们为什么这样做吗？这是一个完全正确的问题，任何个人对代码质量的偏好（可能是错误的和无效的）都不应该成为这样做的理由。我同意你对期望100%覆盖率的看法。对我来说，更多的是强迫症的欲望。在一个项目中，我将try-with-resources重构为几个单独的非常简单的方法，因此我可以轻松地独立地隔离和测试各个部分。谢谢。我大体上同意，但如果你有100%的覆盖率，你一定程度上肯定不会有死代码，因为你在开发测试时至少看过一次你的所有代码，你不必猜测你可以跳过代码的哪些部分，因为它“不是那么重要”。这也是避免出现奇怪但可能出现的语言结构的一个很好的方法。就我的例子（自定义DAO库）而言，使用try-with-resources可以获得的最佳分支覆盖率是57%。你所说的“如果它只有99%，那该怎么办”严重低估了错过的分支的数量。除非你的库都是用资源来尝试的，否则在其他地方进行全面覆盖最终会使try块中错过的几行变得无关紧要，这就是我的意思