15、高效代码设计与测试：原理、策略与实践

高效代码设计与测试：原理、策略与实践

1. 代码设计的关键技术

在代码设计中，有几种关键技术需要我们掌握，包括组合、继承以及通过模块共享行为。这些技术各有优劣，适用于不同的场景。

1.1 组合与继承的选择

在设计对象时，“is - a”（是一个）和“has - a”（有一个）的区别是决定使用继承还是组合的核心。以自行车为例，若要对自行车对象进行建模，最具成本效益的方式是通过组合。组合允许将小部件组合成更复杂的对象，使整体大于部分之和。组合对象通常由简单、离散的实体组成，这些实体易于重新排列成新的组合。简单对象易于理解、复用和测试，但组合成的整体应用程序的操作可能不如单个部分那么容易理解。

一般来说，一个对象的部件越多，就越适合用组合来建模。当深入研究单个部件时，可能会发现某个特定部件有几种特殊变体，这时继承就是一个合理的选择。对于每个问题，我们都需要评估不同设计技术的成本和收益，并根据判断和经验做出最佳选择。

技术	适用场景	优点	缺点
组合	对象部件多	简单实体易理解、复用和测试，可灵活组合	整体操作可能较难理解
继承	特定部件有特殊变体	可复用父类代码，体现“is - a”关系	可能导致代码耦合度高

1.2 代码设计与测试的重要性

编写可更改的代码依赖于三种不同的技能：理解面向对象设计、熟练掌握代码重构以及能够编写高价值的测试。

• 面向对象设计 ：从实际角度看，可更改性是唯一重要的设计指标，易于更改的代码就是设计良好的代码。
• 代码重构 ：根据Martin Fowler的定义，重构是在不改变代码外部行为的前提下改进内部结构的过程。良好的设计通过推迟决策来保持最大的灵活性和最低的成本，当新需求出现时，重构可以将当前代码结构转变为适应新需求的结构。如果重构技能薄弱，就需要加以提升，因为持续重构是良好设计的结果，只有能够轻松重构，设计工作才能充分发挥效益。
• 编写高价值测试 ：测试能让我们有信心不断重构代码。高效的测试可以证明修改后的代码仍然能正确运行，而不会增加总体成本。好的测试能够轻松应对代码重构，代码的更改不会迫使测试重写。

这三种技能就像一个三条腿的凳子，支撑着可更改代码。设计良好的代码易于更改，重构是从一种设计转变到另一种设计的方式，而测试则让我们能够放心地进行重构。

2. 有目的的测试

测试的常见好处包括减少错误、提供文档以及通过先编写测试来改进应用程序设计。但这些好处实际上是一个更深层次目标的代理，测试的真正目的和设计一样，是为了降低成本。

2.1 明确测试意图

测试有许多潜在的好处，深入理解这些好处可以提高我们实现它们的动力。

• 发现错误 ：在开发过程早期发现错误能带来巨大的回报。不仅更容易找到和修复错误，而且尽早让代码正确运行可能会对最终设计产生意想不到的积极影响。随着代码的积累，嵌入式错误会产生依赖关系，后期修复这些错误可能需要更改大量依赖代码，因此尽早修复错误总是能降低成本。
• 提供文档 ：测试是设计的唯一可靠文档。即使纸质文档过时、人类记忆衰退，测试所讲述的故事仍然真实。编写测试时要假设未来的自己会失忆，让测试在我们遗忘时提醒我们。
• 推迟设计决策 ：当测试依赖于接口时，我们可以放心地重构底层代码。测试验证接口的持续良好行为，底层代码的更改不会迫使测试重写。有意依赖接口可以让我们利用测试安全地推迟设计决策，而无需付出代价。
• 支持抽象 ：随着代码库的扩展和抽象数量的增加，测试变得越来越必要。在一定的设计抽象层次上，如果代码没有测试，几乎不可能安全地进行任何更改。测试是每个抽象接口的记录，它们让我们能够推迟设计决策并创建任意深度的抽象。
• 暴露设计缺陷 ：测试可以暴露底层代码的设计缺陷。如果测试需要繁琐的设置，说明代码需要过多的上下文；如果测试一个对象会牵扯到很多其他对象，说明代码的依赖关系过多；如果测试难以编写，其他对象将难以复用该代码。但需要注意的是，昂贵的测试并不一定意味着应用程序设计不佳，为设计良好的代码编写糟糕的测试在技术上是完全可能的。因此，为了让测试降低成本，底层应用程序和测试都必须设计良好。

2.2 明确测试内容

大多数程序员编写的测试过多。为了从测试中获得更好的价值，一个简单的方法是减少测试数量，最安全的做法是只在适当的地方对每件事测试一次。

测试应该集中在跨越对象边界的传入或传出消息上。传入消息构成接收对象的公共接口，对象应该对传入消息返回的状态进行测试。传出消息分为查询消息和命令消息：
- 查询消息 ：没有副作用，只对发送者重要，不需要发送对象进行测试，因为它们是接收者公共接口的一部分，接收者已经实现了所有必要的状态测试。
- 命令消息 ：有副作用（如写入文件、保存数据库记录、观察者采取行动等），发送对象有责任证明这些消息被正确发送，这是对行为的测试，涉及断言消息发送的次数和参数。

总结来说，测试的指导原则如下：
- 传入消息应测试其返回的状态。
- 传出命令消息应测试其是否被发送。
- 传出查询消息不应进行测试。

只要应用程序的对象严格通过公共接口相互交互，测试就不需要了解更多信息。当我们只测试这组最小的消息时，任何对象的私有行为的更改都不会影响任何测试。当我们只测试传出命令消息以证明它们被发送时，松散耦合的测试可以容忍应用程序的更改而无需更改。只要公共接口保持稳定，我们编写一次测试就可以永远保证安全。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(对象):::process -->|传入消息| B(测试返回状态):::process
    A -->|传出消息| C{消息类型}:::process
    C -->|查询消息| D(不测试):::process
    C -->|命令消息| E(测试是否发送):::process

2.3 明确测试时机

只要合理，就应该先编写测试。但对于新手设计师来说，判断何时编写测试可能是一个挑战。

• 新手设计师 ：新手常常编写耦合度太高的代码，将不相关的职责组合在一起，为每个对象绑定许多依赖关系。他们的应用程序是紧密交织的代码，很难进行追溯性测试。先编写测试可以迫使对象从一开始就具备一定的可复用性，否则根本无法编写测试。因此，新手设计师最好编写先测试后编码的代码。虽然缺乏设计技能可能会让这变得非常困难，但只要坚持下去，至少能得到可测试的代码。不过要注意，先编写测试并不能替代或保证设计良好的应用程序，由此产生的应用程序可能仍然远远达不到良好设计的标准。
• 经验丰富的设计师 ：经验丰富的设计师从先测试后编码中获得的改进更为微妙。他们已经能够编写松散耦合、可复用的代码，测试以其他方式增加价值。他们有时会进行“快速实验”，即先编写代码进行探索性实验，一旦明确了设计方向，再回到先测试后编码的方式编写生产代码。

总体目标是创建具有可接受测试覆盖率的设计良好的应用程序。实现这一目标的最佳方法因程序员的优势和经验而异，但无论如何，都不应高估自己的能力而以此为借口跳过测试，应倾向于先编写测试。

2.4 明确测试方法

在选择测试框架时，有很多选择。任何人都可以创建新的Ruby测试框架，但有很多理由选择主流测试框架。主流框架使用的人最多，支持最好，能快速更新以确保与Ruby（和Rails）的新版本兼容，并且大用户群倾向于保持向后兼容性，不太可能迫使重写所有测试，也容易找到有使用经验的程序员。

目前的主流框架有Minitest和RSpec，它们有不同的哲学，你可以根据自己的喜好选择。此外，还需要考虑测试风格，主要有测试驱动开发（TDD）和行为驱动开发（BDD）。

测试风格	方法	优点	缺点
TDD	从内到外，通常从领域对象的测试开始，然后在相邻层代码的测试中复用新创建的领域对象	注重内部逻辑，利于构建基础代码	可能忽略整体业务逻辑
BDD	从外到内，在应用程序边界创建对象并向内推进，必要时进行模拟以提供尚未编写的对象	关注用户需求和行为，利于与业务沟通	可能对底层实现考虑不足

在测试时，将应用程序的对象分为两类：被测试的对象（对象 under test）和其他所有对象。测试必须了解被测试对象的信息，但应尽量对其他对象保持无知。测试的视角也很重要，最好从对象边缘观察，只关注进出的消息，而不是完全进入对象内部，因为这样会增加测试与对象的耦合度，提高代码更改时测试需要重写的可能性。

高效代码设计与测试：原理、策略与实践

3. 测试框架及风格深入解析

在上一部分我们了解了测试框架的选择以及测试风格的基本概念，接下来我们将更深入地探讨这些内容。

3.1 Minitest 框架特点

Minitest 是一个主流的 Ruby 测试框架。由于它是开源软件，当你阅读相关内容时，它可能已经被改进。它具有以下特点：
- 广泛支持 ：拥有大量的用户基础，这意味着在遇到问题时，能够很容易找到相关的帮助和解决方案。
- 兼容性强 ：会及时更新以确保与 Ruby 和 Rails 的新版本兼容，不会成为你跟进新技术的障碍。
- 稳定性高 ：大用户群促使其保持向后兼容性，减少了因框架更新而需要重写大量测试的风险。

在使用 Minitest 进行测试时，我们可以按照以下步骤操作：
1. 安装 Minitest ：如果你使用的是 Ruby 环境，Minitest 通常已经预装。如果没有，可以通过 RubyGems 进行安装。
2. 编写测试用例 ：创建一个测试文件，引入 Minitest 并编写测试代码。例如：

require 'minitest/autorun'

class ExampleTest < Minitest::Test
  def test_example
    assert_equal 2, 1 + 1
  end
end

3. 运行测试 ：在终端中运行测试文件，Minitest 会自动执行测试用例并输出结果。

3.2 RSpec 框架特色

RSpec 也是一个备受欢迎的 Ruby 测试框架，它以行为驱动开发（BDD）为理念，具有以下特色：
- 可读性强 ：使用自然语言描述测试用例，使得测试代码更易于理解，即使是非技术人员也能看懂测试的意图。
- 灵活的匹配器 ：提供了丰富的匹配器，可以方便地进行各种断言操作，使测试代码更加简洁。
- 支持模拟对象 ：在测试中可以方便地使用模拟对象来隔离依赖，提高测试的独立性。

以下是一个使用 RSpec 编写的简单测试示例：

require 'rspec'

describe "Example" do
  it "should add two numbers correctly" do
    expect(1 + 1).to eq(2)
  end
end

RSpec::Core::Runner.run([$__FILE__])

3.3 TDD 与 BDD 的权衡

测试驱动开发（TDD）和行为驱动开发（BDD）虽然看起来有所不同，但实际上它们处于一个连续的光谱上，各有优缺点，适用于不同的场景。

比较维度	TDD	BDD
开发方式	从内到外，先编写领域对象的测试，再逐步构建上层代码	从外到内，先关注应用程序边界的对象，再深入内部
优点	有助于构建坚实的基础代码，确保内部逻辑的正确性	紧密围绕用户需求和行为，便于与业务人员沟通
缺点	可能忽略整体业务逻辑，导致代码与业务需求的契合度不够	可能对底层实现考虑不足，影响代码的可维护性

在实际开发中，我们可以根据项目的特点和团队的情况来选择合适的测试风格。如果项目对内部逻辑的正确性要求较高，或者团队成员更熟悉传统的开发方式，TDD 可能是一个不错的选择；如果项目更注重用户体验和业务需求的实现，或者需要与非技术人员密切合作，BDD 可能更适合。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(项目需求):::process -->|内部逻辑优先| B(选择 TDD):::process
    A -->|用户体验优先| C(选择 BDD):::process

4. 测试实践中的关键要点

在实际的测试过程中，除了选择合适的测试框架和风格外，还需要注意一些关键要点，以确保测试的有效性和效率。

4.1 测试的独立性

测试用例应该相互独立，一个测试用例的执行结果不应该影响其他测试用例。这样可以确保测试结果的准确性，并且在出现问题时更容易定位和修复。为了实现测试的独立性，我们可以采取以下措施：
- 使用隔离技术 ：在测试中使用模拟对象、桩对象等技术来隔离外部依赖，避免测试受到外部环境的影响。
- 清理测试数据 ：在每个测试用例执行前后，清理测试过程中产生的数据，确保测试环境的干净和一致。

4.2 测试的覆盖率

测试覆盖率是衡量测试质量的一个重要指标，它表示代码中被测试覆盖的比例。虽然高覆盖率并不一定意味着代码质量高，但低覆盖率往往意味着代码存在未被测试到的风险。为了提高测试覆盖率，我们可以：
- 全面考虑边界条件 ：在编写测试用例时，要考虑各种边界情况，如输入的最大值、最小值、空值等，确保代码在各种情况下都能正常工作。
- 使用代码覆盖率工具 ：借助代码覆盖率工具来分析测试覆盖情况，找出未被测试到的代码部分，并针对性地编写测试用例。

4.3 测试的维护

随着代码的不断更新和迭代，测试也需要进行相应的维护。为了降低测试维护的成本，我们可以：
- 编写清晰的测试代码 ：测试代码应该具有良好的可读性和可维护性，使用有意义的变量名和注释，便于后续的修改和扩展。
- 及时更新测试用例 ：当代码发生变化时，要及时更新相应的测试用例，确保测试仍然能够准确地反映代码的行为。

5. 总结

通过对代码设计和测试的深入探讨，我们了解到在软件开发过程中，合理运用组合、继承等设计技术，掌握面向对象设计、代码重构和测试编写等技能是非常重要的。同时，有目的的测试，明确测试的意图、内容、时机和方法，选择合适的测试框架和风格，以及注意测试实践中的关键要点，能够帮助我们创建具有可接受测试覆盖率的设计良好的应用程序，降低开发成本，提高代码的可维护性和可靠性。

在未来的开发工作中，我们应该不断实践和总结经验，根据项目的具体情况灵活运用这些知识和方法，以提高软件开发的质量和效率。