学习测试驱动开发

第 12 章 测试顺序 测试秩序

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我的旅程一直是在混乱与秩序之间寻求平衡。

菲利普-佩蒂特

在第 11 章中，我们通过引入Bank 实体，对设计进行了相对重大的改变。我们编写的新测试和现有测试都帮助我们实现了这一目标。

新的Bank 实体的一个特点是能够接受和存储任意货币对之间的汇率。 我们设计（和测试）它的方式--汇率存储在哈希表和由两种货币组成的键中--让我们有理由相信，我们已经拥有了列表中的下一个功能。 该功能允许修改汇率。

要确信该功能可以正常工作，一种方法就是（猜中者无奖）编写一个测试来证明这一点。既然功能很可能已经存在，我们为什么还要写测试呢？换句话说，如果开发工作已经完成，新的测试又能驱动什么呢？

对于这个问题，我们可以给出三个答案：

1. 重复一遍：即使不需要新的生产代码，一个新的测试也会增加我们对这项功能的信心。

2. 新测试将作为该功能的可执行文档。

3. 该测试可能会暴露现有测试之间不经意的交互，从而促使我们解决这些问题。

测试是记录代码的有效方法。因为我们可以（也应该）为测试使用有意义的名称，而且因为它们详细说明了某个功能的作用（而不是它是如何工作的），所以测试是新人了解我们代码的绝佳方式。当我们忘记了代码行为中微妙而重要的细节时，测试甚至可以帮助我们重新定位自己的代码。正如我们将要看到的，编写新的测试可以暴露现有测试中存在的问题。

有了编写测试的理由，让我们把注意力转移到列表中这个可能已实现但尚未测试的功能上：

5 美元 × 2 = 10 美元

10 欧元 × 2 = 20 欧元

4002 韩元 / 4 = 1000.5 韩元

5 美元 + 10 美元 = 15 美元

将测试代码与生产代码分开

删除多余的测试

5 美元 + 10 欧元 = 17 美元

1 美元 + 1100 克鲁瓦 = 2200 克鲁瓦#。

根据涉及的货币确定汇率（从→到）

改进汇率未指定时的错误处理

改进汇率的执行

允许修改汇率

更改汇率

我们首先要修改现有的转换测试。我们已经知道，使用两种货币（如欧元→美元）之间的汇率进行转换是可行的。我们将在测试中为同一货币对添加不同的汇率。我们将验证后续转换是否使用了新汇率。

如果我们的测试能够正常工作，那么我们就能顺利通过绿色阶段。我们将在最后阶段进行必要的重构。

Go

让我们在TestConversion 的末尾再添加几行。我们将把汇率修改为 1.3，并验证它是否生效。 我们还将重命名测试，以反映其意图。下面是整个测试：

func TestConversion(t *testing.T) {
    tenEuros := s.NewMoney(10, "EUR")
    actualConvertedMoney, err := bank.Convert(tenEuros, "USD")
    assertNil(t, err)
    assertEqual(t, s.NewMoney(12, "USD"), *actualConvertedMoney) 

    bank.AddExchangeRate("EUR", "USD", 1.3) 
    actualConvertedMoney ...