为装饰器模式编写 junit 测试的 tdd 步骤答案

【问题标题】：tdd steps to write junit tests for decorator pattern为装饰器模式编写 junit 测试的 tdd 步骤
【发布时间】：2014-04-24 05:16:49
【问题描述】：

是否可以为以下功能编写单元测试？

或者，

是否可以使用 TDD 开发以下功能？

public ZipInputStream getZipInputStream(File zipFile) throws FileNotFoundException {
        ZipInputStream zipInputStream = new ZipInputStream(
                new FileInputStream(zipFile));
        return zipInputStream;
}

我知道这个问题可能听起来很傻，但作为 TTD 的新手，我无法为上述问题找到任何解决方案 :)。

【问题讨论】：

你的问题在哪里？提供一个.zip并测试是否成功，也可以测试异常的抛出。
@laune ：据我了解，您想提供一个真正的 zip 文件。但我在某处读到，真正的 IO 交互不属于单元测试的范畴。单元测试依赖于模拟实例，而不是依赖于真实的文件系统对象、数据库对象等。
好吧，您总是可以编写一个模拟文件系统，将其添加到您的 (Linux) 内核中，等等。 ;-) -- 使用 DB 对象，并且有可以模拟的接口定义的 API，我同意。您可以使用 Readers 和 Writers 为算法编写模拟。但在这里，您正在测试代码调用硬编码类的构造函数，并使用硬编码文件作为参数。

标签： java unit-testing junit tdd

【解决方案1】：

你已经同时提出了两个问题。

是否可以为以下功能编写单元测试？

大多数人不会将此功能的测试视为“单元测试”，因为它必须与文件系统交互。因此，它更像是集成测试而不是单元测试。但是，无论是否可能，这都不是一个好主意。这里没有什么值得测试的。这种方法本身没有任何逻辑，因此测试它没有任何收获。您要测试的只是 Java API。

是否可以使用 TDD 开发以下功能？

使用 TDD 时，您编写的代码符合明确、可测试的要求。这么小的东西不太可能有自己的要求。导致编写此代码的要求将与处理 zip 文件中的数据有关。因此，您将编写一个功能远不止于此的方法 - 当然，在此之前为该方法编写测试。

但是，TDD 过程的第三步是重构。（记住“红色”-“绿色”-“重构”-“红色”-“绿色”-“重构”）。您很可能最终会编写您引用的方法；不是通过尝试使测试工作，而是通过在重构步骤中从更大的方法中提取它。所以答案是肯定的，可以开发此功能，但很可能是在“重构”步骤期间，而不是在“绿色”步骤期间。

【讨论】：

【解决方案2】：

您基本上是在结合 2 个平台调用（new ZipInputStream() 和 new FileInputStream()），没有特定的逻辑或条件。

它是如此简单，以至于我什至不会费心去测试它。

在任何情况下，您都无法测试 装饰器模式，因为它不是由您实现的。装饰器本身就是ZipInputStream。

【讨论】：

【解决方案3】：

您可以尝试编写一个测试方法来接收输入流来装饰您将提供的模拟 ZipFile。创建模拟，以便它返回假 ZipEntry 实例，您可以稍后根据 ZipInputStream 的 getNextEntry() 方法验证这些实例。

通过这种方式，您可以测试返回的 ZipInputStream 是否真的在装饰提供的 ZipFile（我建议使用诸如 testReturnedZipInputStreamDecoratesProvidedZipFile() 之类的名称或类似的名称...）。

【讨论】：

如果能提供代码示例就好了。
抱歉，我错了，我以为您传递的是 ZipFile 作为参数，而不是 File。
如果传递 ZipFile 可以使我们的功能更可测试，那么我们也可以这样做。如果我们遵循，请您分享一些代码，通过 ZipFile 方法。
我不确定这将如何工作，因为它们接收不同的输入。 ZipFile 与 File 输入一起使用，而 ZipInputStream 与 InputStream 一起使用。我不确定它是否可以通过这种方式进行测试，即使您将 File 参数更改为 InputStream，测试这种方法似乎也很麻烦。