三个 A（或given, when, then）为了更好地构建和查找依赖关系，使用arrange,act或,可能会assert有所帮助。通过在单元测试中写下这三个关键字作为注释，将单元测试分为三个区域。givenwhenthen
arrange（或者given）这是进行测试准备的地方，定义变量并设置所有其他配置。这是我们对单元测试的介绍，有助于我们更好地理解单元测试应该涵盖的情况。如果所有单元测试都有相同的测试准备，那么它们可以而且应该外包。所有常见的测试框架，例如 JUnit 或 Jest，通常都提供可以外包我们的测试准备工作的设置选项。在 Jest 中，这些是函数beforeEach和beforeAll。在 JUnit 中，注释@BeforeEach和@BeforeAll.
act（或者when）
这是实际测试执行发生的地方。这意味着这里调用了要测试的方法或函数。
assert（或者then）
在这个领域，我们的测试结果是通过将结果与我们的期望进行比较来以 列表构建mlm 编程方式评估的。原则上，单元测试应该只期望和评估一个结果。这意味着单元测试通常只包含一个assert() 或expect() 调用。
为了更容易理解，举个小例子：
假设我们有一家在线猫用品商店，并希望为所有高级客户提供 15% 的折扣。我们有一个 REST 接口，可以通过该接口向用户提供折扣（例如GET /v1/discount）。就我个人而言，我更喜欢Given- when-then表示法，因为它允许我们预先用散文形式简单地制定单元测试：
给定具有高级状态的用户
当该用户提出请求时
那么用户应该获得 15% 的折扣
在具体的单元测试中，这看起来像这样
不用担心，您不需要在单元测试中编写超过given, whenandthen或arrange, actand 的内容。assert我在这里这样做只是为了让您更好地理解从上面的散文文本到实际测试实现的过渡。
将单元测试分为这三个区域可以提高可读性，从而帮助我们发现依赖关系，特别是当测试设置不仅仅是一行代码时。原则上，我们可以像看一个小故事一样来阅读我们的单元测试。在该区域中，我们有given一个介绍，其中构建了我们的故事（或我们的单元测试）。然后，紧张局势在该区域达到顶峰when，在该区域中发生了具体的行动（测试执行）。现在该地区的故事then即将结束，我们将行动的结果与我们之前对故事的期望进行比较。诚然，这不是一个特别令人兴奋的故事，因为我们提前做出了假设，这些假设应该在故事结束时实现。但这正是我们在单元测试中想要的：满足期望。最终，一个好的单元测试应该像一个简单的故事一样容易理解。因此，不应该有任何突然的站点故事（代码中的跳转）迫使我作为读者在故事中来回跳转以了解更大的图景，而是我只想从上到下阅读单元测试底下，可以理解。