它应该是“安排—声明—行为—声明”吗？

关于Arrange-Act-Assert的经典测试模式，我经常发现自己在Act之前添加了反主张。这样，我知道传递的断言实际上是作为操作结果传递的。

我认为它类似于红色-绿色-重构中的红色，在红色-绿色-重构中，只有在测试过程中看到红色条时，我才知道绿色条表示我已经编写了有区别的代码。如果我编写了通过测试，那么任何代码都可以满足要求；类似地，对于“安排—断言—行为—断言”，如果我的第一个断言失败，我知道任何法案都会通过最终的断言，因此实际上并没有验证有关该法案的任何内容。

您的测试是否遵循这种模式？为什么或者为什么不？

更新说明：初始声明与最终声明实质上相反。这不是Arrange工作的断言；有人断言该法案尚未生效。

这不是最常见的做法，但仍然足够常见以拥有自己的名称。此技术称为“ 警卫断言”。您可以在第490页的Gerard Meszaros 撰写的出色的xUnit Test Patterns（强烈推荐）一书中找到它的详细说明。

通常，我自己不会使用此模式，因为我发现编写特定的测试来验证我认为需要确保的任何前提条件更为正确。如果前提条件失败，则此类测试应始终失败，这意味着我不需要将其嵌入所有其他测试中。由于一个测试用例只能验证一件事，因此可以更好地隔离问题。

对于给定的测试用例，可能需要满足许多先决条件，因此您可能需要多个Guard Assertion。不必在所有测试中都重复这些测试，而是对每个前提条件进行一个（仅一个）测试可以使您的测试代码更易于维护，因为这样您的重复次数会更少。

也可以将其指定为Arrange- Assume -Act-Assert。

NUnit中对此有一个技术性的处理，例如此处的示例：http : //nunit.org/index.php? p=theory&r= 2.5.7

这是一个例子。

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”。在第一个断言的上下文中读到，它的意思是：“断言调用contain（）会使它包含7。由于contains是我们正在测试的单元，因此我认为它具有一些（较小）价值。

我接受自己的回答；许多其他人误解了我的问题，有关测试设置。我认为这略有不同。

一个Arrange-Assert-Act-Assert测试始终可以重构为两个测试：

1. Arrange-Assert

和

2. Arrange-Act-Assert

第一个测试仅声明在“安排”阶段中设置的内容，第二个测试仅声明在“ Act”阶段中发生的内容。

这样做的好处是，对于原始阶段的“安排”或“法案”阶段失败，可以提供更精确的反馈 Arrange-Assert-Act-Assert它们是混杂的，因此您必须更深入地研究并确切地检查断言是什么以及为什么断言才能知道是否是安排或法案失败了。

由于将测试分为较小的独立单元，因此它也更好地满足了单元测试的意图。

最后，请记住，每当您在不同的测试中看到类似的“安排”部分时，都应尝试将其引入共享的帮助器方法中，以使您的测试将来更干燥，更易于维护。

我现在正在这样做。另一种AAAA

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

更新测试示例：

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

原因是ACT不包含ReadUpdated的读取，是因为它不属于该行为。该行为只是在改变和保存。所以说真的，ARRANGE ReadUpdated用于断言，我正在调用ASSEMBLE进行断言。这是为了防止混淆ARRANGE部分

ASSERT应该只包含断言。这就在ACT和ASSERT之间保留了ASSEMBLE，从而建立了断言。

最后，如果您未通过Arrange，则您的测试不正确，因为您应该进行其他测试来防止/发现这些琐碎的错误。因为对于我目前存在的场景，应该已经有其他测试来测试READ和CREATE。如果创建“保护声明”，则可能会破坏DRY并创建维护。

在执行要测试的动作之前，先通过“健全性检查”断言来验证状态是一种古老的技术。我通常将它们写为测试脚手架，以向自己证明该测试能够达到我的期望，并在以后删除它们以避免测试脚手架使测试混乱。有时，将脚手架留在里面有助于测试作为叙述。

我已经读过有关此技术的信息-也许是从您那里得到的-但我不使用它；主要是因为我习惯了单元测试的Triple A形式。

现在，我很好奇，并提出了一些问题：如何编写测试，在执行红绿红绿重构周期之后，是否使该断言失败，还是在事后添加它？

有时在重构代码后是否会失败？这告诉你什么？也许您可以分享一个有帮助的例子。谢谢。

在调查失败的测试之前，我已经做到了。

经过相当大的挠头后，我确定原因是“整理”期间调用的方法无法正常工作。测试失败具有误导性。我在安排之后添加了断言。这使得测试无法通过突出实际问题的地方进行。

我认为，如果测试的“安排”部分过长且过于复杂，这里也会有代码异味。

总的来说，我非常喜欢“安排，行动，断言”并将其用作我的个人标准。但是，它没有提醒我要做的一件事是，当断言完成时，我会重新安排我已经安排的内容。在大多数情况下，这不会引起太多麻烦，因为大多数事情会通过垃圾回收等自动消失。但是，如果您已建立与外部资源的连接，则可能需要在完成后关闭这些连接有了您的断言，或者您有很多服务器或昂贵的资源可以保持连接或重要资源的使用，而这些资源应该可以分配给其他人。如果您要不使用TearDown或TestFixtureTearDown的开发人员之一，在一项或多项测试后进行清理。当然，“安排，行动，断言”对我未能关闭我所打开的内容不负责；我只提到此“陷阱”，因为我还没有找到推荐的“ dispose”的良好“ A字”同义词！有什么建议？

看一下Wikipedia在“ 按合同设计”上的条目。Arrange-Act-Assert三位一体是对某些相同概念进行编码的一种尝试，它与证明程序的正确性有关。从文章：

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

在设置此功能所花费的精力与其增加的价值之间需要权衡。AAA是一个有用的提醒，它提示了所需的最少步骤，但不应阻止任何人创建其他步骤。

取决于您的测试环境/语言，但是通常如果“编配”部分中的某些操作失败，则会引发异常，并且测试无法显示该异常，而不是启动“ Act”部分。所以不，我通常不使用第二个断言部分。

另外，如果您的Arrange部分非常复杂且并不总是引发异常，则您可能会考虑将其包装在某种方法中并为其编写自己的测试，因此可以确保它不会失败（没有引发异常）。

我不使用该模式，因为我认为这样做：

Arrange
Assert-Not
Act
Assert

可能没有意义，因为据说您知道您的“编配”部分正常工作，这意味着“编排”部分中的所有内容也必须进行测试，或者必须足够简单才能进行测试。

使用您的答案示例：

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

如果您真的想测试示例中的所有内容，请尝试更多测试……

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

因为否则，您会错过很多错误的可能性...例如，在包含之后，范围仅包括7，等等...还对范围的长度进行了测试（以确保不包含随机值），并且另一组完全试图将范围5包含在内的测试...我们期望什么-包含范围中的异常或范围未更改？

无论如何，关键是您要检验的行为中是否有任何假设，将其置于自己的测试中，是吗？

我用：

1. Setup
2. Act
3. Assert 
4. Teardown

因为干净的安装非常重要。