我知道这个问题与之前发布的其他问题非常相似，但我想以适当的方式讨论这个话题。
你认为“明显”的异常应该进行单元测试吗？
除了明显的异常，我的意思是例如由于空参数或空字符串或负数导致的异常，在我们单元的业务逻辑使我们很明显这些异常将始终在我们的方法开始时抛出的情况下在任何其他操作之前。
换句话说，我说的是在违反类契约的最简单部分后应该抛出的异常。
感谢您的意见。
【问题讨论】：
标签： unit-testing exception design-by-contract
当然。你称它们为“显而易见的”，但记住验证先决条件并没有什么明显的。事实上，我在职业生涯中看到的大部分代码都没有采取这种明显的步骤来防止以后出现混乱。
虽然您在为公共消费、重用等而编写的库代码中经常看到这一点，但大多数开发人员似乎常常忘记将此类检查放入自己的代码中。在测试驱动的环境中，对此类条件进行测试会迫使开发人员正确验证其公共方法的输入参数。
说句公道话……我有机会再写一个测试并看到绿色条，我很高兴。 :)
【讨论】：
我也总是为这种“简单、明显”的事情写一个测试，主要是因为
【讨论】：
我通常包括这些测试。它实际上是一个开始开发的好地方，因为如果您使用 TDD，您可以通过最简单的测试来开始编写生产代码，如果您不使用 TDD，您可以通过一个很好的测试:)
【讨论】：
是的，您应该对 getter 和 setter 中最简单的逻辑进行单元测试。如果代码在重构期间发生更改，您希望单元测试安全网到位，以确保不会出现错误。运行测试是一种快速发现这些错误的方法。
我不测试 getter 和 setter 的唯一情况是它们是否仅进行简单的赋值或返回值。
【讨论】：