我应该为每个断言创建一个新的测试方法吗？

Question

我知道这是主观的，但我想遵循最常见的做法。 你通常为每个类方法创建一个测试方法，并用多个断言填充它，或者你是否为每个断言创建一个测试方法？

例如，如果我正在测试银行帐户的withdraw方法，并且我想确保在用户尝试透支帐户或撤回负数时抛出异常，我应该创建{{1 }}和testOverdaw，或者我只是将这两个断言合并到一个名为testNegativeWithdrawal的方法中？

Answer 1

以这种方式思考：每个测试应该独立存在并运用相对独立的功能集。如果你想断言关于你创建的某个方法的三个方面是否正确，那么你应该创建一个包含这三个方面的测试。

因此，我必须强烈反对已经回答的其他人。任意限制自己每次测试一个断言对你没有任何作用，除非让你的测试变得笨拙乏味。最终它可能会让你完全放弃测试 - 这肯定是一种耻辱：对你的项目和职业生涯不利。

现在，不意味着您拥有编写大型，笨拙或多用途测试例程的许可。实际上，我认为我从来没有写过超过20行左右的那篇。

当知道哪个断言在一个函数中有多个时失败时，你会注意到当断言失败时，nUnit和MSTest都会给你一个描述和一个链接，它会把你带到违规行（nUnit会需要一个集成工具，如TestDriven.net）。这使得找出失败点变得微不足道。两者都将在函数中的第一次失败时停止，并且两者都使您能够进行调试演练。

Answer 2

就个人而言，我会为每个断言创建一个测试，否则你必须挖掘才能找到失败的原因，而不是从测试名称中显而易见。

如果您必须编写几行代码来设置测试并且不想复制它，那么根据您的语言和测试框架，您应该能够创建一组测试，其中每个测试将执行一个代码块在运行之前。

Answer 3

制作多种测试方法;不要将它们合二为一。您的每个测试方法都应测试该方法的一种行为。正如您所说，使用负余额进行测试是一种不同的行为，然后以正余额进行测试。那么，这将是两次测试。

您希望这样做，以便在测试失败时，您不会试图找出该测试中的哪个部分失败。

Answer 4

一种方法是为每种不同的场景或设置提供一种单独的方法。在您的情况下，您可能想要一个有足够资金的场景，以及一个资金不足的场景。并声称在第一个中一切都有效，而在第二个中，相同的操作将不起作用。

Answer 5

我建议每个断言使用一个测试方法，或者更确切地说，按照预期的行为。如果任何测试失败，这允许更快地本地化错误代码。

Answer 6

我会做出这两个单独的断言。

第一个表示如果用户定期使用该帐户将会发生的有效操作，第二个表示未完成数据清理或未正确完成的情况。

您需要单独的测试用例，以便您可以根据需要在逻辑上实现测试用例，尤其是在运行所有测试可能非常昂贵的回归方案中。

Answer 7

testOverdraw和testNegativeWithdrawal是两种不同的行为。它们应单独测试。

一个好的经验法则是在一个单元测试中对被测方法只有一个动作（不计算设置和断言）。

Answer 8

从NUnit文档中： “如果断言失败，则方法调用不会返回并报告错误。如果测试包含多个断言，那么失败的断言将不会被执行。因此，通常最好尝试一个断言。试验“。

http://www.nunit.org/index.php?p=assertions&r=2.4.6

然而，没有什么能迫使您遵循最佳实践。如果这个特定项目不值得您花费时间和精力进行100％粒度测试，其中一个错误意味着一个测试失败（反之亦然），那么就不要这样做。最终，它是您可以以最佳成本/收益平衡使用的工具。这种平衡取决于许多特定于您的方案的变量，并且特定于每个项目。