您如何在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

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

在每个测试类中，我的组织结构并不多。每个人只有一些方法可以测试被测试的每个公共方法，所以我从来没有遇到任何问题找到我正在寻找的东西。

Answer 4

对于软件中的每个类，我都维护一个单元测试类。单元测试类遵循与测试的类相同的包层次结构。

我将单元测试代码保存在一个单独的项目中。有些人还喜欢将他们的测试代码保存在名为“test”的单独源目录下的同一个项目中。你可以跟随任何你觉得舒服的事情。

Answer 5

我尝试将单元测试视为一个项目。与任何项目一样，组织应遵循一些内部逻辑。然而，它不必具体或正式定义 - 只要它能使您的项目井井有条，干净整洁，您所能接受的任何事情都可以。

因此，对于单元测试，我通常要么遵循主项目代码结构，要么（有时在情况调用时）专注于功能区域。

将它们留在一个堆中就像你可能想象的那样混乱且难以维护