我知道这是主观的，但我想遵循最常见的做法。 您是否通常为每个类方法创建一个测试方法，并使用多个断言来填充它，或者是否为每个断言创建一个测试方法？我应该为每个断言创建一个新的测试方法吗？
例如，如果我测试一个银行帐户的withdraw方法，我想确保，如果用户试图透支帐户或撤销负数抛出一个异常，我应该创建testOverdaw和testNegativeWithdrawal，或将我只是将这两个断言结合在一个名为testWithdraw的方法中？
想想这样：每个测试都应该独立运行，并且运行一组相对独立的功能。如果您想断言您所创建的某种方法是否有三件事是真的，那么您应该创建一个包含这三件事的测试。
因此，我不得不强烈反对其他人的回答。任意限制自己对每个测试的一个断言将不会为你做任何事情，除非让你的测试笨重和乏味。最终它可能会让你完全失望 - 这肯定是一种耻辱：对你的项目和职业不利。
现在，而不是表示您有许可编写大型，笨重或多用途测试例程。的确，我认为我从来没有写过20行左右的文章。
只要知道哪一个断言失败时，在一个函数中有几个，你会注意到当断言失败时，nUnit和MSTest都会给你一个描述和一个链接，它会将你带到违规行（nUnit将需要一个集成工具，如TestDriven.net）。这使得找出失败点微不足道。两者都会停止在函数中的第一次失败，并且都会让您有能力进行调试演练。
我同意这一点，但我看到这种方法的一个缺点。如果您正在执行三个断言来测试三种不同的场景，并且在运行测试时第一个失败。另外两个断言呢？你不知道他们是否会成功或失败。你打破了你的三个场景还是只有一个或两个？任何虽然？ – joerage 2009-12-14 02:10:33
好问题。首先，请记住，测试中的所有断言应该是相关的。如果失败了，这可能会对其他人产生影响。因此，在确定其他人之前，我必须解决第一个问题。其次，在我的工作风格中，失败的测试是立即修复的原因。所以我不担心其他两个，直到我得到第一个固定。也就是说，我将在紧密循环中修复和测试该功能，直到所有功能都得到验证。所以，如果其他人失败了，我可以通过修正第一个来解决它们。如果他们没有失败，重新测试会立即告诉我。 – 2009-12-14 03:59:36
@joerage为什么不解决问题，重新运行测试并查看其他声明是否失败？ – cbp 2009-12-15 00:07:01
做出多种测试方法;不要把它们合并成一个。每种测试方法都应该测试方法的一种行为。正如你所说，测试时使用负平衡是一种不同的行为，然后以正平衡进行测试。所以，这将是两个测试。
你想这样做，这样当一个测试失败时，你不会试图找出那个测试中的哪个部分失败。
就我个人而言，我会为每个断言创建一个测试，否则您必须挖掘以找出失败的原因，而不是从测试名称中显而易见。
如果您必须编写几行代码来设置测试并且不想重复测试，那么根据您的语言和测试框架，您应该能够创建一组测试，其中每个测试都将执行它运行之前的一段代码。
+1 ...余额 – Paul 2009-12-14 01:20:55
我会建议有一个测试方法每个断言，或者说是一个预期的行为。这样可以更快地定位错误代码，如果有任何测试失败。
我会做出这两个单独的断言。
第一个表示如果用户定期使用该帐户会发生的有效操作，第二个表示数据清理未完成或未正确完成的情况。
您需要单独的测试用例，以便您可以根据需要在逻辑上实施测试用例，尤其是在回归场景中，运行所有测试的成本过高。
其中一种方法是针对每种不同场景或设置使用一种单独的方法。在您的情况下，您可能需要一个场景，其中有足够的资金，以及一个场景资金不足。并断言在第一个一切正常，并在第二个相同的操作不起作用。
testOverdraw和testNegativeWithdrawal是两个单独的行为。他们应该分开测试。
一个很好的经验法则是在一个单元测试中对被测方法只有一个动作（不包括设置和断言）。
从NUnit文档： “如果断言失败，方法调用不会返回并报告错误。如果测试包含多个断言，那么失败的后面的任何断言都不会执行。 ，通常每个测试都要尝试一个断言。“
http://www.nunit.org/index.php?p=assertions&r=2.4.6
然而，没有任何强迫你遵循最佳做法。如果这个特定项目不值得花时间和精力进行100％细粒度测试，其中一个bug意味着一个测试失败（反之亦然），那么不要这样做。最终，它是一种工具，您可以使用最佳的成本/收益平衡。这种平衡取决于许多特定于您的方案的变量，并且针对每个项目。
在我看来，你至少应该测试0和max（数字），这样做很明显，它只是简单到最后有一个已知的初始状态，并使它们都是单独的测试。 – 2009-12-14 08:28:03