unit-testing - 您如何在 TDD 中组织单元测试？

Question

我做 TDD，我在组织单元测试方面相当松散。我倾向于从代表下一个故事或功能 block 的文件开始，并编写所有单元测试以使其工作。

当然，如果我要引入一个新类，我通常会为该类制作一个单独的单元测试模块或文件，但我不会将测试本身组织成任何更高级别的结构。结果是我快速编写代码，并且我相信我的实际程序结构合理，但是单元测试本身是“困惑的”。特别是，它们的结构倾向于概括发展过程的系统发育。有时我认为自己是在用代码中的懒惰来换取测试中的懒惰。

这是一个多大的问题？谁在这里不断地重构和重组他们的单元测试以试图改进他们的整体结构？对此有什么建议吗？测试的整体结构应该是什么样子。

(请注意，我在这里问的不是“每个函数有多少断言”问题:How many unit tests should I write per function/method? 我说的是更大的图景。)

Answer 1

将您的测试分为 2 组:

功能测试

单元测试

功能测试是每个用户的故事。单元测试是按类进行的。前者检查你是否真的支持这个故事，后者练习并记录你的功能。

有一个用于功能测试的目录(包)。单元测试应该与它们使用的功能紧密结合(所以它们是分散的)。当您移动和重构代码时，您可以移动它们并重构它们。