unit-testing - 当它导致 *更少* 测试时，我应该使用 "glass box"测试吗？

Question

例如，我正在编写针对 CsvReader 的测试。这是一个枚举和拆分文本行的简单类。它唯一的存在理由是忽略引号内的逗号。不到一页。

通过“黑盒”测试类，我检查了类似的东西

• 如果文件不存在怎么办？
• 如果我没有文件的权限怎么办？
• 如果文件有非 Windows 换行符怎么办？

但实际上，所有这些都是 StreamReader 的事情。我的类(class)在没有对这些案例做任何事情的情况下工作。所以本质上，我的测试是捕捉 StreamReader 抛出的错误，以及框架处理的测试行为。感觉像是白费了很多功夫。

我看过相关问题

• Should QA test from a strictly black-box perspective?
• Rigor in capturing test cases for unit testing

我的问题是，如果我使用我所知道的避免这种工作，我是否错过了“玻璃盒”测试的意义？

Answer 1

这实际上取决于您的 CsvReader 的接口(interface)，您需要考虑该类的用户期望什么。

例如，如果其中一个参数是文件名并且该文件不存在应该发生什么？这不应该取决于您是否使用流阅读器。单元测试应该测试你的类的可观察的外部行为，在某些情况下，要稍微深入一点，另外确保覆盖某些实现细节，例如阅读器完成后关闭文件。

但是，您不希望单元测试依赖于所有细节，或者假设由于实现细节而发生某些事情。

您在问题中提到的所有示例都涉及您的类(class)的可观察行为(在这种情况下是异常(exception)情况)，因此应该有与之相关的单元测试。