测试指南 – 我们驱动设计

在第 5 章《编写我们的第一个测试》中，我们编写了我们的第一个测试。为了做到这一点，我们经历了许多设计决策。让我们回顾一下最初的测试代码，并列出我们必须做出的所有设计决策，如下所示：

@Test
public void oneIncorrectLetter() {
    var word = new Word("A");

    var score = word.guess("Z");

    assertThat( score.letter(0) ).isEqualTo(Letter.INCORRECT);
}

我们做出了以下决定：

测试什么
测试的名称
被测试方法的名称
将该方法放在哪个类上
该方法的签名
类的构造函数签名
哪些其他对象应该协作
协作中涉及的方法签名
该方法的输出形式
如何访问该输出并断言其工作

这些都是我们人类必须做出的设计决策。TDD 让我们在设计代码和决定如何实现代码时非常亲力亲为。老实说，我对此感到高兴。设计是有回报的，TDD 提供了有用的脚手架，而不是规定性的方法。TDD 作为一个指南，提醒我们尽早做出这些设计决策。它还提供了一种将这些决策记录为测试代码的方式。仅此而已，但同样，也不少。

在我们做出这些决策时，使用结对编程或群体编程（也称为合奏编程）等技术可能会有所帮助——这样，我们就为我们的解决方案增加了更多的经验和更多的想法。独自工作时，我们只能根据自己的经验做出最好的决策。

这里要传达的关键点是，TDD 不能也不会为我们做出这些决策。我们必须做出这些决策。因此，有一些指导原则来引导我们走向更好的设计是有用的。一组被称为 SOLID 原则的五个设计原则是有帮助的。SOLID 是以下五个原则的首字母缩写：

单一职责原则（SRP）
开闭原则（OCP）
里氏替换原则（LSP）
接口隔离原则（ISP）
依赖倒置原则（DIP）

在接下来的部分中，我们将学习这些原则是什么，以及它们如何帮助我们编写良好设计的代码和测试。我们将从 SRP 开始，这可以说是任何程序设计风格中最基础的原则。