你如何在TDD中组织你的单元测试？

Question

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

当然，如果我要引入一个新类，我通常会为该类创建一个单独的单元测试模块或文件，但我不会将测试本身组织到任何更高级别的结构中。结果是我写代码很快，我相信我的实际程序结构相当好，但单元测试本身是“混乱”的。特别是，它们的结构倾向于概括发展过程的发展史。有时，我认为自己在用代码中的懒惰来换取测试中的懒惰。

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

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

Answer 1

将你的测试分成两组：

• 功能测试
• 单元测试

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

有一个用于功能测试的目录(包)。单元测试应该与它们执行的功能紧密地绑定在一起(所以它们是分散的)。当你移动和重构你的代码时，你可以移动它们并重构它们。

Answer 2

不太重要的部分是组织测试。

我首先将测试放入一个与被测试类相关的类中，因此com.jeffreyfredrick.Foo有一个测试com.jeffreyfredrick.FooTest。但是，如果这些类的某些子集需要不同的设置，那么我将把它们移到它们自己的测试类中。我将测试放在一个单独的源目录中，但将它们放在同一个项目中。

更重要的部分是重构测试。

是的，我试着边走边重构我的测试。这样做的目的是消除重复，同时仍然保持声明式和易读性。无论是在测试类内还是跨测试类，都是如此。在一个测试类中，我可能有一个参数化的方法来创建一个测试伪(模拟或存根)。我的测试伪装通常是测试类中的内部类，但如果我发现有需要，我会把它们拉出来，以便在测试中重用。如果合适的话，我还将创建一个TestUtil类，其中包含通用方法。

我认为重构你的测试对于大型项目单元测试的长期成功很重要。你有没有听过人们抱怨他们的测试太脆弱或者阻止了他们的改变？您不希望处于这样的境地:更改一个类的行为意味着要对测试进行数十次甚至数百次更改。就像代码一样，你可以通过重构和保持测试的整洁来实现这一点。

测试是代码。

Answer 3

我为应用程序中的每个类编写了一个单元测试类，并将测试类组织在与被测试类相同的包结构中。

在每个测试类中，我并没有太多的组织结构。对于被测试的类中的每个公共方法，每个方法都只有几个方法，所以我在找到我要找的东西时从来没有遇到过任何问题。