关于安排-行动-断言的经典测试模式,我经常发现自己在法案之前添加了一个反断言。通过这种方式,我知道传递断言实际上是作为操作的结果传递的。
我认为它类似于红色的红绿重构,只有当我在测试过程中看到红色条形图的时候,我才知道绿色条形图意味着我已经编写了不同的代码。如果我编写了一个通过测试,那么任何代码都会满足它;类似地,关于安排-断言-动作-断言,如果我的第一个断言失败了,我知道任何法案都会通过最终断言--这样它实际上就不会验证关于该法案的任何内容。
您的测试是否遵循此模式?为什么或者为什么不?
更新澄清:初始断言与最终断言本质上是相反的。这不是一种“安排成功”的断言,而是一种“法案”尚未奏效的断言。
发布于 2009-06-23 18:59:14
下面是一个例子。
public void testEncompass() throws Exception {
Range range = new Range(0, 5);
assertFalse(range.includes(7));
range.encompass(7);
assertTrue(range.includes(7));
}可能是我编写Range.includes()只是为了返回true。我没有,但我可以想象我可能有。或者我可以用其他任何方式写错。我希望并期望通过TDD,我实际上是正确的-- includes()只是起作用了--但也许我没有。因此,第一个断言是一个理智检查,以确保第二个断言是真正有意义的。
assertTrue(range.includes(7));自己读到:“断言修改后的范围包括7”。在第一个断言的上下文中,它是这样说的:“断言调用since ()会导致它包含7,而且由于since是我们正在测试的单元,所以我认为这是一些(小的)值。
我正在接受我自己的答案;其他许多人把我的问题误解为是关于测试设置的。我觉得这有点不同。
发布于 2009-06-20 05:39:04
这不是最常见的事情,但仍然足够普遍,有自己的名字。这种技术被称为“守护断言”。您可以在Gerard的优秀书籍“xUnit测试模式”(Gerard)中找到关于它的详细描述(高度推荐)。
通常,我自己并不使用这个模式,因为我发现编写一个特定的测试来验证我觉得需要确保的任何前提条件是更正确的。如果前提条件失败,这样的测试总是失败的,这意味着我不需要将它嵌入到所有其他测试中。这提供了更好的关注点隔离,因为一个测试用例只验证一件事情。
对于给定的测试用例,可能需要满足许多先决条件,因此您可能需要一个以上的守护断言。与其在所有测试中重复这些测试,不如为每个先决条件设置一个(和一个)测试,从而使您的测试代码更易于执行,因为这样您的重复次数就会更少。
发布于 2010-08-19 18:59:04
它也可以指定为安排-假设-行动-断言。
在NUnit中有一个技术句柄,如下面的示例:http://nunit.org/index.php?p=theory&r=2.5.7
https://stackoverflow.com/questions/1021007
复制相似问题