unit-testing - 如何编写 "dirty"单元测试？

Question

我正在阅读代码完成。在那本书中，Steve McConnell 警告说“开发人员测试往往是'干净的测试'。开发人员倾向于测试代码是否有效(干净测试)，而不是测试代码中断的所有方式(脏测试)。”

我如何为代码中断的方式编写测试？我的意思是，我可以为错误的输入编写测试并确保它被正确阻止。但除此之外，我应该考虑哪些事情？麦康奈尔在这里是什么意思？我对基本的单元测试很满意，但试图掌握它。

Answer 1

我认为你在这里走在正确的道路上。证明代码有效的测试将调用具有合理、有意义和预期输入的方法，程序处于正常状态。虽然打破代码的测试尝试对那段代码进行“开箱即用”的思考，从而使用任何无意义或意外的输入。

恕我直言，重要的是要了解这两种思维过程是非常不同的。当开发人员以 TDD 方式编写代码时，他(她)倾向于关注要在代码中实现的各种功能，以及证明这一和那一点功能或用例按规定工作的测试。以这种方式创建的测试就是麦康奈尔所说的“干净的测试”。

考虑如何破坏一段代码需要非常不同的思维过程和不同的经验。它需要从不同的角度查看您的方法和 API，例如暂时把你对这些方法和参数的目的的了解放在一边，只关注技术上可以用它们做的事情。还要考虑此方法正常工作所需的所有 - 通常是隐含的 - 先决条件或依赖项。它是否取决于从数据库读取的配置参数？它是否写入文件系统？它是否调用另一个组件，期望它事先正确初始化？它是否使用大量内存？它是否在 GUI 上显示一条消息？...如果其中一个或多个不成立怎么办？

所有这些都会引出一些重要的问题:你的方法应该如何处理这种肮脏的情况？ 它应该崩溃吗？抛出异常？继续尽其所能？返回错误代码？记录错误报告？...所有这些或大或小的决定对于正确且一致地定义方法或 API 的契约实际上非常重要。

Kent Beck 谈到在同一意义上在“开发人员帽子”和“测试人员帽子”之间切换。以这种方式流畅地转换观点和思维过程需要练习和经验。