每个方法都应该有一个单独的JUnit测试类吗？

我正在为我的课程编写JUnit单元测试。

为每个方法设置一个单独的类，还是为每个实际类仅设置一个测试类，更好？

与完全进行测试的重要性相比，测试的组织方式并不重要。

一个好的测试套件最重要的是它涵盖了所有功能。这样可以确保每当引入回归缺陷时，您都会立即注意到。为每种方法编写一个测试，为一个方法的每个输入值组合编写一个测试，还是为该方法中的每个可能的代码路径编写一个测试，都没有那么重要。将这些测试分为几个或几个测试类甚至没有那么重要：一个测试套件应始终完全成功，因此，它是否通过了17项测试中的3项或2项都不重要-两者都是错误的，必须是固定。

当然，测试代码也是代码，因此它应遵循正常的最佳实践以实现可维护性，模块化等。但这必须取决于测试套件本身的可维护性，而不是取决于测试类与测试套件之间的关系。他们测试的课程。您提到的两个策略都可以帮助您记住在一致地遵循条件的情况下从哪里查找内容，但是对于此，一致性比选择策略更为重要。

为了您的具体问题，JUnit的惯例，是有一个1：您的应用程序类之间的一一对应（Foo1.java，Foo2.java和JUnit测试类（） ，）。Foo1Test.javaFoo2Test.java

也就是说，我完全同意Kilian强调单元测试的精神/目标对可能使用的任何组织方案的重要性。选择一些约定并在大多数时候坚持使用，同时在必要时谨慎地允许约定的例外。

为每个方法设置一个单独的类，还是为每个实际类仅设置一个测试类，更好？

如果您需要为一个类的方法编写单独的测试类，那么您的设计有误。方法应小巧，易读，易于测试且易于更改。由于组成了testdata，mocking等，测试可能会比原始代码长一些，但不应过长。如果是这样，则您正在测试的类太复杂了，并且肯定会做很多事情（单一职责原则）：在您的设计上工作。

我认为“每个方法一个测试类”和“每个类一个测试类”通常都太极端了。

通常，您希望对每个测试方法/单元测试进行一次检查。例如，这些可以是多个断言来检查list.isEmpty = true和list.Length = 0，因此每个行为一个测试方法/单元测试。

这样就很容易拿出描述行为的测试方法名称。您希望将测试方法分组到一个测试类中，因此，当您阅读时test classname.test method，这很有意义。通常，它们具有一些共享的设置代码，然后可以轻松地将它们放入测试设置/装置中。根据要测试的类，这可以是整个类的一个测试类，也可以是一个方法的一个测试类。但通常，它会介于两者之间。

与普通代码一样，您希望测试尽可能可读。对我来说有帮助的是按照给定的BDD（何时，然后是行为声明）的方式组织测试代码。一个测试类可以给定它，它是设置程序。然后，该类中的每个测试方法都使用该给定的（或部分）测试方法，并且在某时有一个。

还可以将单元测试视为有关如何使用被测类功能的文档。使用良好的单元测试，您可以阅读测试以了解如何使用您要使用的类的功能以及效果将是什么。

当某件事坏了并且单元测试失败时，您希望它尽可能容易地了解什么坏了，每个测试一个断言在这里很有帮助。当一个测试中有多个断言时，只有第一个断言失败，然后该方法退出，因此，在解决导致第一个断言失败的问题之前，您不知道在随后的测试中测试的其他行为是否也被破坏。有了一个断言，您所有其他测试方法仍然可以执行，并且了解失败的深度要快得多。

当然，我同意Kilian Foth的观点：实际上，您可以幸运地为正在处理的代码进行了一些单元测试。而且，任何小型的本地化测试总比没有测试要好，或者仅在构建服务器上运行的大型集成测试会花费很多时间，而且通常不是非常本地化（它们不会告诉您错误的位置-您将需要做一些工作）。

我认为每个课程都有其测试课程是正确的。这个想法是将与目标类相关的所有单元测试集中在一个测试类中。然后，例如，MyClass.java将其测试类称为MyClassTest.java。

最好还是问同事，是否有关于如何在公司中进行测试的文档，或者他们遵循的方式是什么。如果您遵循他们的指南，则可以使您的测试对其他人更具可读性。