我知道这个问题与以前发布的其他问题非常相似，但我想以适当的方式讨论这个话题。
你认为“明显的”例外应该进行单元测试吗？
明显的异常我的意思是例如由于空参数或空字符串或负数而导致的异常，在我们单元的业务逻辑使我们明白这些异常将始终在我们的方法的开头被抛出的情况下在任何其他操作之前。
换句话说，我说的是在违反类合同最简单部分后应该抛出的异常。
感谢您的意见。
答案 0 :(得分：8)
绝对。你称之为“显而易见”，但记住验证前置条件并没有什么明显之处。事实上，我在职业生涯中看到的大部分代码都没有采取这一明显的措施来防止以后的混乱。
虽然你在为公共消费，重用等编写的库代码中看到了很多，但是记住将这些检查放入自己的代码中似乎经常被大多数开发人员忽略。在测试驱动的环境中，为这些条件进行测试会迫使开发人员在其公共方法上正确验证输入参数。
让我们公平......我有机会再写另一个测试并看到绿色的酒吧，我很高兴。 ：）
答案 1 :(得分：3)
我总是也会为这种“简单明了”的事情写一个测试，主要是因为
答案 2 :(得分：1)
我通常包括这些测试。它实际上是一个开始开发的好地方，因为如果您使用TDD，您可以使用最简单的测试来开始编写生产代码，如果您不使用TDD，您可以通过一个很好的通过测试：）
答案 3 :(得分：0)
是的，你应该对你的getter和setter中最简单的逻辑进行单元测试。如果在重构期间代码发生变化，您需要使用单元测试安全网来确保没有错误。运行测试是一个很快就能找到这些错误的方法。
我唯一没有测试getter和setter的是他们只进行 简单赋值或返回值。