后置条件是一种(类型)单元测试吗？

Question

我正在尝试将一些按合同设计的技术融入到我的编码风格中.后置条件看起来像嵌入式单元测试对我来说很多,我想知道我的思路是在正确的轨道还是偏离基础.

维基百科将后置条件定义为"条件或谓词,在执行某些代码段之后或在正式规范中的操作之后必须始终为真.后置条件有时使用代码本身中的断言进行测试".

这与您在直接验证状态的单元测试中所做的不同(不使用模拟)吗？

如果是这样的话:

1)通过使用后置条件,我现在不是在我的生产代码中嵌入测试代码,并不是不赞成的吗？

2)使用后置条件是否应该改变单元测试的结构？我的第一个想法是断言逻辑从测试转移到后置条件.也就是说,测试将使用相同的输入,我仍然在测试我之前测试的所有内容,但现在不是在单元测试中进行断言,而是在对后置条件传递与否进行简单的二元断言.

3)我的第二个想法是后置条件代码可能具有控制流,因此不适用于测试代码,这应该是简单的并且避免控制流.但是,如果我测试后置条件,我可以在单元测试中依赖它们吗？

4)测试后置条件似乎很困难,因为如果我正确理解它们,它们基本上是通过或失败的,你必须重复后置条件本身的逻辑来检查它是否正确.那么,你如何测试后置条件？您是否通过在单元测试中不使用它们并确保您的单元测试和后置条件一起通过或失败来检查它们？

5)我的单元测试有时会验证方法是否导致协作者状态发生变化.在标准实践中,后置条件是否涵盖协作者状态或仅定义它们所定义的类的状态？

Answer 1

您走在正确的轨道上。

的确，后置条件与单元测试的目的相似。关键区别在于后置条件始终运行，而单元测试仅针对一组已知数据运行。这意味着后置条件不太可能会忽略您没有想到的极端情况，但在运行时会更加昂贵。

这是您的特定问题的答案。

1. 后置条件会导致运行时损失。但是（取决于您的环境），可能会为了速度放弃声明。（在C语言中，您可以使用#ifdef，在Java中查找AOP，在Python中assert，只要传递--debug标志等，任何内容都可以运行。）如果从断言中遇到性能问题，则可以解决。但是，我倾向于将它们保留，直到您有理由不这样做为止。

2. 您的某些逻辑自然会从单元测试转移到后置条件。但是，有必要确保对后置条件进行所有感兴趣的案例都可以运行单元测试。如果您为了提高速度而放弃生产中的断言，则尤其如此。

3. 后置条件不是单元测试。用对他们的工作有意义的任何方式写它们。（通常，它们应该有点简单。）

4. 通常，您按照＃2中的说明测试后置条件，方法是传入一组可能会违反后置条件的感兴趣的输入，并检查是否符合条件。如果要测试后置条件本身的逻辑，则可以设置可能违反后置条件但仅在测试期间运行的代码。例如，有一个可以测试的全局变量，可以设置该变量（如果已设置），则用您想要的任何值替换要返回的数据。现在，您可以使后置条件接收您想要的任何输入。

5. 我不会给你硬性规定。他们是你的合同。他们应该说出该功能在做什么有意义。就是说，您所描述的内容可能导致这些对象之间的紧密耦合。紧耦合是您应该有充分理由做的事情。