我做 TDD，我在组织单元测试方面相当松散。我倾向于从代表下一个故事或功能块的文件开始，并编写所有单元测试以使其工作。
当然，如果我要引入一个新类，我通常会为该类制作一个单独的单元测试模块或文件，但我不会将测试本身组织成任何更高级别的结构。结果是我快速编写代码，并且我相信我的实际程序结构合理，但是单元测试本身是“混乱的”。特别是，它们的结构倾向于概括发展过程的系统发育。有时我认为自己是在用代码中的懒惰来换取测试中的懒惰。
这是一个多大的问题？谁在这里不断地重构和重组他们的单元测试以试图改进他们的整体结构？对此有什么建议吗？测试的整体结构应该是什么样子。
（请注意，我并不是在问“每个函数有多少断言”问题：我应该为每个函数/方法编写多少单元测试？我说的是更大的图景。）
将您的测试分为 2 组：
功能测试是每个用户的故事。单元测试是按类进行的。前者检查你是否真的支持这个故事，后者练习并记录你的功能。
有一个用于功能测试的目录（包）。单元测试应该与它们使用的功能紧密结合（所以它们是分散的）。当您移动和重构代码时，您可以移动它们并重构它们。
不太重要的部分是组织测试。
我首先将测试放入与被测类相关的类中，因此 com.jeffreyfredrick.Foo 有一个测试 com.jeffreyfredrick.FooTest。但是，如果这些类的某些子集需要不同的设置，那么我会将它们移动到它们自己的测试类中。我将我的测试放到一个单独的源目录中，但将它们保存在同一个项目中。
更重要的部分是重构测试。
是的，我尝试重构我的测试。目标是在保持声明性和易读性的同时消除重复。在测试类和跨测试类中都是如此。在测试类中，我可能有一个用于创建测试假（模拟或存根）的参数化方法。我的测试假货通常是测试类中的内部类，但如果我发现有需要，我会将它们拉出来以便在测试中重用。如果合适，我还将创建一个带有常用方法的 TestUtil 类。
我认为重构你的测试对于大型项目的单元测试的长期成功很重要。你有没有听过人们抱怨他们的测试太脆弱或阻止他们改变？您不希望处于更改类的行为意味着对测试进行数十甚至数百次更改的位置。就像代码一样，您可以通过重构和保持测试干净来实现这一点。
测试就是代码。
我为应用程序中的每个类编写一个单元测试类，并将测试类组织在与被测类相同的包结构中。
在每个测试类中，我并没有太多的组织结构。对于被测类中的每个公共方法，每个方法只有少数方法，因此我在查找所需内容时从来没有遇到任何问题。
对于软件中的每个类，我维护一个单元测试类。单元测试类遵循与被测试类相同的包层次结构。
我将单元测试代码保存在一个单独的项目中。有些人还喜欢将他们的测试代码保存在同一个项目中的一个名为“test”的单独源目录下。你可以跟随任何你觉得舒服的事情。
我尝试将单元测试视为一个项目。与任何项目一样，组织应该遵循一些内部逻辑。然而，它不必是具体的或正式的定义——只要它使您的项目保持井井有条和干净，任何您觉得舒服的东西都可以。
所以对于单元测试，我通常要么遵循主要的项目代码结构，要么（有时当情况需要它时）专注于功能区域。
将它们放在一堆中就像您想象的那样混乱且难以维护