unit-testing - 参数异常应该进行单元测试吗？

Question

我知道这个问题与之前发布的其他问题非常相似，但我想以适当的方式讨论这个话题。

您认为应该对“明显”异常进行单元测试吗？

对于明显的异常，我的意思是例如由于空参数或空字符串或负数而导致的异常，在这种情况下，我们单元的业务逻辑使我们很明显，这些异常总是在我们的方法开始时抛出，在任何其他异常之前手术。

换句话说，我说的是在违反类契约的最简单部分后应该抛出的异常。

谢谢您的意见。

Answer 1

绝对地。你称它们为“显而易见的”，但记住验证先决条件并没有什么明显的。事实上，我在职业生涯中看到的大部分代码都没有采取这种明显的步骤来防止以后出现混乱。

虽然您在为公共消费、重用等而编写的库代码中经常看到这一点，但大多数开发人员似乎常常忘记将此类检查放入自己的代码中。在测试驱动的环境中，对此类条件进行测试会迫使开发人员正确验证其公共方法上的输入参数。

说句公道话……我有机会再写一个测试并看到绿色条，我很高兴。:)

Answer 2

我也总是为这种“简单、明显”的事情写一个测试，主要是因为

• 针对这些“明显”情况的相应测试通常写得很快，因此我在快速编写它时几乎更快，而不是考虑是否进行测试的事实
• 一个简单的测试用例总比没有测试用例好
• 测试未来的变化。进行测试可确保我团队中的任何其他开发人员在重构/错误修复等期间不会破坏我的代码......

Answer 3

我通常包括这些测试。它实际上是开始开发的好地方，因为如果您使用 TDD，您可以通过最简单的测试来开始编写生产代码，如果您不使用 TDD，您可以通过一个很好的测试 :)

Answer 4

是的，您应该对 getter 和 setter 中最简单的逻辑进行单元测试。如果代码在重构过程中发生变化，您希望单元测试安全网到位，以确保不会出错。运行测试是一种快速发现这些错误的方法。

我唯一不测试 getter 和 setter 的情况是它们是否只进行简单的赋值或返回值。