应该是“安排-断言-行动-断言”吗？

Question

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

我认为它类似于红绿重构中的红色，只有当我在测试过程中看到红色条时，我才知道绿色条意味着我已经编写了有所作为的代码。 如果我编写了一个通过测试，那么任何代码都可以满足它； 类似地，对于 Arrange-Assert-Act-Assert，如果我的第一个断言失败，我知道任何法案都会通过最终的断言 - 因此它实际上并没有验证有关该法案的任何内容。

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

更新澄清：初始断言本质上与最终断言相反。 这并不是断言 Arrange 有效；而是说 Arrange 有效。 这是一个断言，该法案尚未发挥作用。

Answer 1

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

1. Arrange-Assert

第

2. Arrange-Act-Assert

一个测试将仅断言在 Arrange 阶段设置的测试，第二个测试将仅断言行动阶段发生的事情。

这样做的好处是可以提供更准确的反馈，判断是安排阶段还是行动阶段失败，而在原始的 Arrange-Assert-Act-Assert 中，这些是混杂在一起的，您必须深入挖掘并了解准确检查哪些断言失败以及失败的原因，以便了解失败的是安排还是行动。

它还更好地满足了单元测试的目的，因为您将测试分成更小的独立单元。

Answer 2

我现在正在做这个。 不同类型的 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 的读取的原因是它不是 Act 的一部分。 该行为只是改变和拯救。 所以实际上，ARRANGE ReadUpdated 进行断言，我正在调用 ASSEMBLE 进行断言。 这是为了防止混淆 ARRANGE 部分

ASSERT 应该只包含断言。 这使得 ASSEMBLE 位于 ACT 和 ASSERT 之间，用于设置断言。

最后，如果您在安排中失败，则您的测试不正确，因为您应该进行其他测试来防止/发现这些微不足道的错误。 因为对于我提出的场景，应该已经有其他测试来测试 READ 和 CREATE。 如果您创建“Guard Assertion”，您可能会破坏 DRY 并创建维护。

Answer 3

在执行正在测试的操作之前加入“健全性检查”断言来验证状态是一种旧技术。 我通常将它们编写为测试脚手架，以向自己证明测试符合我的预期，并稍后删除它们以避免测试脚手架造成测试混乱。 有时，保留脚手架有助于测试发挥叙事作用。

Answer 4

总的来说，我非常喜欢“Arrange、Act、Assert”，并将其作为我个人的标准。 然而，它没有提醒我去做的一件事是，在断言完成后打乱我已经安排的事情。 在大多数情况下，这不会造成太多烦恼，因为大多数事情都会通过垃圾收集等自动消失。但是，如果您已经建立了与外部资源的连接，那么您可能希望在完成后关闭这些连接根据您的断言，或者您可能在某处拥有一台服务器或昂贵的资源，保留着连接或重要资源，这些资源应该能够赠送给其他人。 如果您是这样做的开发人员之一，这一点尤其重要在一项或多项测试后不要使用 TearDown 或 TestFixtureTearDown 进行清理。 当然，“Arrange、Act、Assert”并不对我未能关闭我打开的内容负责； 我只提到这个“陷阱”，因为我还没有找到一个好的“处置”同义词来推荐！ 有什么建议么？

Answer 5

我不使用这种模式，因为我认为做类似的事情：

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));
}

Answer 6

我已经读过有关此技术的内容 - 可能是从您那里顺便说一句 - 但我不使用它； 主要是因为我习惯了单元测试的 3A 形式。

现在，我很好奇，并且有一些问题：您如何编写测试，是否会导致此断言失败，遵循红-绿-红-绿-重构循环，还是之后添加它？

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

Answer 7

我以前在调查失败的测试时曾这样做过。

经过一番苦思冥想后，我确定原因是“排列”期间调用的方法无法正常工作。 测试失败具有误导性。 我在安排后添加了一个断言。 这使得测试在突出实际问题的地方失败。

我认为如果测试的排列部分太长太复杂，这里也会有代码味道。

Answer 8

查看 Wikipedia 关于Design by Contract 的条目。 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 是对所需最少步骤的有用提醒，但不应阻止任何人创建额外的步骤。

Answer 9

取决于您的测试环境/语言，但通常如果 Arrange 部分中的某些内容失败，则会引发异常，并且测试无法显示它，而不是启动 Act 部分。 所以不，我通常不使用第二个 Assert 部分。

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

Answer 10

如果你真的想测试示例中的所有内容，请尝试更多测试...例如：

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 的测试......我们会期望什么 - 包含中的例外，或不改变的范围？

无论如何，重点是如果您想测试该行为中的任何假设，请将它们放入自己的测试中，是吗？

Answer 11

我使用：

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

因为干净的设置非常重要。

Answer 12

这不是最常见的事情，但仍然很常见，有自己的名字。 这种技术称为“Guard Assertion”。 您可以在 Gerard Meszaros 所著的优秀著作《xUnit Test Patterns》（强烈推荐）的第 490 页上找到它的详细描述。

通常，我自己不会使用这种模式，因为我发现编写一个特定的测试来验证我认为需要确保的任何前提条件更为正确。 如果前提条件失败，这样的测试应该总是失败，这意味着我不需要将它嵌入到所有其他测试中。 这可以更好地隔离关注点，因为一个测试用例仅验证一件事。

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

Answer 13

它还可以指定为 Arrange-Assume-Act-Assert。

NUnit 中有一个技术处理方法，如下例所示：
http://nunit.org/index.php?p=theory&r =2.5.7

Answer 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”。 在第一个断言的上下文中阅读，它说：“断言调用包含（）会导致它包含7。并且由于包含是我们正在测试的单元，我认为这是一些（小）值。

我接受我自己的答案；很多其他人误解了我的问题是关于测试设置。