Java 6 中的单元测试最终受阻

Question

在检查我的代码覆盖率时，我注意到很多单元测试无法检查尝试关闭finally块中打开的InputStreams的finally块。

一个示例摘录是：

  try {
      f = new BufferedInputStream(new FileInputStream(source));
      f.read(buffer);
  } finally {
      if (f != null)
          try {
              f.close();
          } catch (IOException ignored) {
          }
      }
  }

是否有任何适当的解决方案可以使用 JUnit4 检查 finally 块内的所有内容？

我知道在保持最大生产力的同时，无法实现 100% 的代码覆盖率。然而，这些红线在报告中颇为引人注目。

Answer 1

首先考虑使用 IOUtils.closeQuietly()，这会将未经测试的代码（可能还有重复）减少为：

  try {
      f = new BufferedInputStream(new FileInputStream(source));
      f.read(buffer);
  } finally {
      IOUtils.closeQuietly(f);
  }

现在变得很困难。 “正确”的方法是将 BufferedInputStream 的创建外部化到另一个类中并注入模拟。通过模拟，您可以验证是否调用了适当的 close() 方法。

@JeffFoster 的答案与我的意思非常接近，但是我建议组合而不是继承（以更多代码为代价）：

  try {
      f = fileSystem.open(source);
      f.read(buffer);
  } finally {
      IOUtils.closeQuietly(f);
  }

其中 fileSystem 是 < code>FileSystem 接口，在生产代码或模拟中注入简单的实际实现以进行测试。

interface FileSystem {

    InputStream open(String file);

}

外部化文件打开的另一个好处是，如果您决定删除缓冲或添加加密，则只需修改一个位置。

有了这个接口，您就可以使用模拟实例化您的测试代码（使用 Mockito）：

//given
FileSystem fileSystemMock = mock(FileSystem.class);
InputStream streamMock = mock(InputStream.class);

given(fileSystemMock.open("file.txt")).willReturn(streamMock);

//when
//your code

//then
verify(streamMock).close();

Answer 2

您可以将代码重构

public class TestMe {
  public void doSomething() {
    try {
      f = new BufferedInputStream(new FileInputStream(source));
      f.read(buffer);
    } finally {
      if (f != null)
      try {
          f.close();
      } catch (IOException ignored) { }
    }
  }
}

为类似这样的代码

public class TestMe {
  public void doSomething() {
    try {
      f = createStream()
      f.read(buffer);
    } finally {
      if (f != null)
      try {
          f.close();
      } catch (IOException ignored) { }
    }
  }

  public InputStream createStream() {
      return new BufferedInputStream(new FileInputStream(source));
  }
}

，现在您可以编写测试来捕获输入流类并验证其是否已关闭。 （代码很粗糙，但希望您能了解总体思路）。

public void TestSomething () {
   InputStream foo = mock(InputStream.class); // mock object
   TestMe testMe = new TestMe() {
     @Override
     public InputStream createStream() {
          return foo;
     } 
   }

   testMe.something();

   verify(foo.close());
}

这是否值得是另一个问题！

Answer 3

您应该注入一个模拟的 BufferedInputStream - 或使用工厂创建它 - 当调用模拟的 close() 方法时，然后抛出 IOException。

另外，我不会在上面的finally 块中添加任何逻辑，除非其中没有任何逻辑。

Answer 4

我认为您需要问自己这是否真的值得进行测试。一些测试迷往往会错过尝试达到 100% 测试覆盖率所带来的收益递减。在这种情况下，看起来一些建议的解决方案为实际代码添加了更多复杂性，以使其“可测试”。我对复杂的测试代码很满意，但是仅仅为了使其“可测试”而向实际代码添加复杂性对我来说是一个糟糕的主意。