【发布时间】：2012-10-20 20:09:49
【问题描述】：
所以，Guava 有简单而有用的Preconditions 来检查方法参数。但我想也有一个“后置条件”类是合理的。还是仅仅因为 java 提供了断言？
由于不存在这样的课程，在数学返回之前检查后置条件的“最佳”（实践）替代方法是什么？
【问题讨论】：
-
使用单元测试或Java的
assert声明
【发布时间】：2012-10-20 20:09:49
【问题描述】：
测试后置条件是多余的。 我们在java中测试后置条件的方式是unit testing。
通过单元测试，我们确保对于给定的输入，我们得到可预测的输出。使用Preconditions，我们可以验证我们有有效的输入，因此测试已经保证了输出。
【讨论】：
-
单元测试主要服务于公共接口测试。因此，例如测试私有方法不会那么“方便”。在那种情况下，我想某种形式的后置条件会派上用场。看来我必须使用本机 java“断言”。
-
一个问题是如果你should首先测试
private方法。一种选择是更改可见性，例如，使用protected。 -
我不赞成改变单元测试的可见性。我个人使用反射来测试我认为需要测试的任何内容，而无需更改代码。
我会在方法本身中使用 Java assert 关键字来编码后置条件。
单元测试还是后置条件？
单元测试和后置条件有不同的用途。
单元测试中的断言提供了对方法的结果的检查对于一个输入向量。它是一个预言机，指定一个特定案例的预期结果。
方法中的assert 本身验证对于任何输入 后置条件成立。它是一个为所有可能的情况指定预期结果（属性）的预言。。
这种作为预言机的后置条件与自动化测试技术很好地结合在一起，在这些技术中，很容易生成输入，但很难为每个输入生成预期值。
Guava 后置条件？
至于为什么 Guava 有 Precondition 类，而没有 Postcondition 类，这是我的理解。
Guava Preconditions 有效地为您希望根据方法的输入或对象的输入抛出特定类型的异常（非法参数、空指针、索引越界、非法状态）的常见情况提供了一些简写。状态。
对于后置条件，此类常见情况较少。因此，不需要提供速记来抛出特定类型的异常。失败的后置条件就像 HTTP 500“内部服务器错误”——我们都知道执行我们的方法出了点问题。
（请注意，Guava 的前提条件概念与纯 design-by-contract 的概念完全不同，后者根本无法保证如果不满足前提条件 - 甚至不会抛出合理的异常。Guava 的 Preconditions 类提供使公共 API 更具防御性的有用功能）。
【讨论】：
前置条件和后置条件的用途截然不同。
前置条件测试输入，它不受方法的控制；后置条件测试输出，即。因此，它们在方法本身内部没有意义，而只是作为测试方法的外部代码。
然而，如果你真的想在你的代码中加入这样的断言，Guava Preconditions 也可以很好地实现这一点，即使这不是它们的预期目的。
【讨论】：
-
Guava Preconditions 报告失败，异常告诉客户端（方法用户）客户端做错了什么（非法参数、空指针、索引越界、非法状态）。正如您所说，相比之下，失败的后置条件表明方法/服务器中出现了问题。最有可能的是，这将需要抛出不同的异常，从而使 Guava.Preconditions 的使用对检查后置条件的用处不大。