因此，Guava具有简单但有用的Preconditions来检查方法参数。但我想有一个“后置条件”类也是合理的。或者只是因为java提供了断言？
由于这样的类不存在，在mathod返回之前检查postonditions的“最佳”（练习）替代方法是什么？
答案 0 :(得分：16)
测试后期条件是多余的。 我们在java中测试后置条件的方式是unit testing。
通过单元测试，我们确保对于给定的输入我们获得可预测的输出。使用Preconditions，我们可以验证我们是否有有效输入，因此测试已经保证了输出。
答案 1 :(得分：13)
我会在方法本身中使用Java assert关键字对后置条件进行编码。
单元测试或后置条件？
单元测试和后置条件有不同的用途。
单元测试中的断言提供了对一个输入向量的方法的结果的检查。这是一个oracle，指定了一个特定案例的预期结果。
方法中的assert 会验证后置条件保留的是否为任何输入。它是一个oracle，为所有可能的情况指定预期结果的（属性）。
这样的后置条件与oracle结合良好的自动化测试技术很容易生成输入，但很难为每个输入生成预期值。
番石榴后置条件？
至于为什么Guava有一个Precondition类，但没有Postcondition类，这是我的理解。
Guava Preconditions有效地为常见情况提供了许多简介，在这些情况下，您希望根据方法的输入或对象的方式抛出特定类型的异常（非法参数，空指针，索引越界，非法状态）状态。
对于后置条件，这类常见案例较少。因此，不需要提供速记抛出特定种类的例外。失败的后置条件就像HTTP 500“内部服务器错误” - 我们知道执行我们的方法时出错了。
（注意，番石榴的前提条件概念与纯design-by-contract的概念完全不同，其中如果不满足前提条件则根本没有保证 - 甚至不会抛出合理的异常。番石榴的前提条件class提供了有用的功能，使公共API更具防御性。）
答案 2 :(得分：9)
先决条件和后置条件的用途非常不同。
前提条件测试输入，不受方法控制; postconditions测试输出，即。因此，它们在方法本身内部没有意义，但仅作为测试方法的外部代码。
但是，如果你真的想在你的代码中加入这样的断言，那么Guava Preconditions也会很好地服务于它，即使这不是他们的预期目的。