例如，我正在针对 CsvReader 编写测试。这是一个简单的类，用于枚举和分割文本行。这只是存在的理由忽略引号内的逗号。它还不到一页。
通过“黑盒”测试课程，我检查了诸如
- 如果文件不存在怎么办？
- 如果我没有该文件的权限怎么办？
- 如果文件包含非 Windows 换行符怎么办？
但事实上，所有这些事情都是StreamReader的事。我的班级没有对这些案例做任何事情。所以本质上，我的测试是捕获 StreamReader 抛出的错误，并测试框架处理的行为。感觉做了很多工作却毫无结果。
我看过相关问题
-
QA 是否应该从严格的黑盒角度进行测试？ https://stackoverflow.com/questions/164170/should-qa-test-from-a-strictly-black-box-perspective
- 严格捕获单元测试的测试用例 https://stackoverflow.com/questions/12569/rigor-in-capturing-test-cases-for-unit-testing
我的问题是，如果我使用我所知道的东西，我是否错过了“玻璃盒”测试的要点avoid这种工作？
这实际上取决于 CsvReader 的接口，您需要考虑该类的用户的期望。
例如，如果参数之一是文件名，而该文件不存在，会发生什么情况？这不应该取决于您是否使用流读取器。单元测试应该测试类的可观察的外部行为，并且在某些情况下，要稍微深入一些，并另外确保涵盖某些实现细节，例如读者完成后文件将关闭。
但是，您不希望单元测试依赖于所有细节，或者假设由于实现细节而会发生某些事情。
您在问题中提到的所有示例都涉及班级的可观察行为（在本例中为特殊情况），因此应该有与它们相关的单元测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
