MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

Ruby测试驱动开发（TDD）的完整指南

2022-04-264.1k 阅读

Ruby测试驱动开发（TDD）基础概念

什么是测试驱动开发（TDD）

测试驱动开发（Test - Driven Development，TDD）是一种软件开发方法，它以编写测试用例作为开发的起点。其核心流程是：先编写一个失败的测试，这个测试描述了我们期望程序具备的功能；然后编写实现代码使测试通过；最后对代码进行重构以优化结构和性能。这种方法有助于确保代码的正确性、可维护性和可扩展性。

TDD在Ruby中的重要性

在Ruby开发中，TDD尤为重要。Ruby作为一种动态、灵活的语言，很容易写出看似功能正常但在复杂场景下隐藏问题的代码。通过TDD，我们可以在开发过程中及时发现并修复这些问题。同时，TDD编写的测试用例就像是代码的文档，清晰地展示了每个模块的功能和预期行为，方便其他开发者理解和维护代码。

Ruby测试框架——MiniTest和RSpec

MiniTest简介

MiniTest是Ruby标准库的一部分，它提供了一个简单而轻量级的测试框架。MiniTest使用断言（assertions）来验证代码的预期行为。例如，要测试一个简单的加法函数：

require 'minitest/autorun'

def add(a, b)
  a + b
end

class AddTest < MiniTest::Test
  def test_addition
    assert_equal(5, add(2, 3))
  end
end

在上述代码中，我们定义了一个add函数，然后使用MiniTest创建了一个测试类AddTest，其中的test_addition方法使用assert_equal断言来验证add(2, 3)的结果是否等于5。

RSpec简介

RSpec是一个流行的行为驱动开发（Behavior - Driven Development，BDD）框架，它的语法更具描述性，强调行为和场景。例如，同样测试上述加法函数：

require 'rspec'

def add(a, b)
  a + b
end

describe 'add function' do
  it 'adds two numbers correctly' do
    expect(add(2, 3)).to eq(5)
  end
end

在RSpec中，我们使用describe块来描述要测试的对象（这里是add function），it块来描述具体的行为（adds two numbers correctly），并使用expect和to组合来验证结果。

以一个简单项目为例进行TDD开发

项目需求

假设我们要开发一个简单的计算器程序，它可以进行加、减、乘、除运算。

使用MiniTest进行TDD开发

  1. 编写第一个失败的测试 我们先从加法运算开始。

    require 'minitest/autorun'

class CalculatorTest < MiniTest::Test
  def test_addition
    calculator = Calculator.new
    result = calculator.add(2, 3)
    assert_equal(5, result)
  end
end

    此时运行测试，会因为Calculator类不存在而失败。

  2. 编写实现代码使测试通过

    class Calculator
  def add(a, b)
    a + b
  end
end

    再次运行测试，测试通过。

  3. 重构代码 目前代码很简单，重构空间不大。但随着功能增加，我们可以考虑优化代码结构，比如将不同运算方法进行更好的组织。

使用RSpec进行TDD开发

  1. 编写第一个失败的测试

    require 'rspec'

describe Calculator do
  describe '#add' do
    it 'adds two numbers correctly' do
      calculator = Calculator.new
      expect(calculator.add(2, 3)).to eq(5)
    end
  end
end

    运行测试，因为Calculator类不存在而失败。

  2. 编写实现代码使测试通过

    class Calculator
  def add(a, b)
    a + b
  end
end

    测试通过。

  3. 重构代码 同样，随着功能的扩展，可以对代码结构进行优化，例如将Calculator类的不同运算方法按照功能模块进行划分。

测试驱动开发中的测试类型

单元测试

单元测试是TDD中最基本的测试类型，它专注于测试单个单元（例如一个方法或一个类）的功能。在我们的计算器示例中，对Calculator类的add方法的测试就是单元测试。单元测试应该是独立的，不依赖外部系统（如数据库、网络服务等），这样可以确保测试的可靠性和快速性。例如，对于Calculator类的subtract方法的单元测试：

# MiniTest单元测试
require 'minitest/autorun'

class Calculator
  def subtract(a, b)
    a - b
  end
end

class CalculatorSubtractTest < MiniTest::Test
  def test_subtraction
    calculator = Calculator.new
    result = calculator.subtract(5, 3)
    assert_equal(2, result)
  end
end

# RSpec单元测试
require 'rspec'

class Calculator
  def subtract(a, b)
    a - b
  end
end

describe Calculator do
  describe '#subtract' do
    it 'subtracts two numbers correctly' do
      calculator = Calculator.new
      expect(calculator.subtract(5, 3)).to eq(2)
    end
  end
end

集成测试

集成测试用于测试多个单元之间的交互。在计算器项目中，如果我们要测试先加法再减法的连续操作，就需要集成测试。假设我们在Calculator类中添加一个chain_operations方法：

class Calculator
  def add(a, b)
    a + b
  end

  def subtract(a, b)
    a - b
  end

  def chain_operations(a, b, c)
    result = add(a, b)
    subtract(result, c)
  end
end

# MiniTest集成测试
require 'minitest/autorun'

class CalculatorIntegrationTest < MiniTest::Test
  def test_chain_operations
    calculator = Calculator.new
    result = calculator.chain_operations(5, 3, 2)
    assert_equal(6, result)
  end
end

# RSpec集成测试
require 'rspec'

describe Calculator do
  describe '#chain_operations' do
    it 'performs chained addition and subtraction correctly' do
      calculator = Calculator.new
      expect(calculator.chain_operations(5, 3, 2)).to eq(6)
    end
  end
end

集成测试确保了不同单元之间协同工作的正确性，但由于可能涉及多个单元的交互，运行速度可能比单元测试慢。

功能测试

功能测试关注的是系统作为一个整体的功能是否满足需求。在Web应用开发中，功能测试可以模拟用户在浏览器中的操作，检查页面是否正确渲染、表单提交是否成功等。例如，使用Capybara（一个用于Ruby的Web应用测试工具）进行功能测试： 假设我们有一个简单的Ruby on Rails应用，有一个用于计算两个数字之和的表单。

# Gemfile中添加
# gem 'capybara', '~> 3.36'
# gem 'rspec-rails', '~> 4.0'

# spec/features/calculator_feature_spec.rb
require 'rails_helper'

RSpec.feature 'Calculator feature' do
  scenario 'User can calculate sum' do
    visit '/'
    fill_in 'Number 1', with: '2'
    fill_in 'Number 2', with: '3'
    click_button 'Calculate'
    expect(page).to have_content('The sum is 5')
  end
end

在上述代码中，我们使用Capybara模拟用户访问页面、填写表单并点击按钮，然后验证页面上是否显示了正确的计算结果。功能测试可以帮助我们发现系统级别的问题，确保应用满足用户的实际需求。

测试替身（Test Doubles）

什么是测试替身

在TDD中，当被测试的单元依赖于其他对象时，为了隔离测试并控制测试环境，我们使用测试替身。测试替身是真实对象的替代品，它们模拟真实对象的行为，但具有更简单和可控制的特性。常见的测试替身类型有：桩（Stubs）、模拟对象（Mocks）和伪造对象（Fakes）。

桩（Stubs）

桩用于提供预定义的响应，而不关心方法是否被调用。例如，假设Calculator类依赖于一个外部的日志记录服务LoggerService来记录计算结果。我们可以使用桩来模拟LoggerService的行为，以便在测试Calculator时不受其影响。

class LoggerService
  def log(message)
    # 实际实现可能会写入文件或发送到日志服务器
    puts message
  end
end

class Calculator
  def initialize(logger)
    @logger = logger
  end

  def add(a, b)
    result = a + b
    @logger.log("The result of adding #{a} and #{b} is #{result}")
    result
  end
end

# 使用MiniTest和桩进行测试
require 'minitest/autorun'

class StubLogger
  def log(message)
    # 简单返回，不进行实际日志记录
  end
end

class CalculatorWithStubTest < MiniTest::Test
  def test_addition_with_stub
    stub_logger = StubLogger.new
    calculator = Calculator.new(stub_logger)
    result = calculator.add(2, 3)
    assert_equal(5, result)
  end
end

# 使用RSpec和桩进行测试
require 'rspec'

class StubLogger
  def log(message)
    # 简单返回，不进行实际日志记录
  end
end

describe Calculator do
  let(:stub_logger) { StubLogger.new }
  let(:calculator) { Calculator.new(stub_logger) }

  describe '#add' do
    it 'adds two numbers correctly with stub' do
      expect(calculator.add(2, 3)).to eq(5)
    end
  end
end

在上述代码中，StubLogger就是一个桩，它提供了log方法的简单实现，使我们可以专注于测试Calculator的add方法，而不依赖真实的LoggerService。

模拟对象（Mocks）

模拟对象不仅提供预定义的响应，还验证特定方法是否被调用。例如，我们希望确保Calculator在计算后确实调用了LoggerService的log方法。

# 使用RSpec和模拟对象进行测试
require 'rspec'

describe Calculator do
  let(:mock_logger) { double('LoggerService') }
  let(:calculator) { Calculator.new(mock_logger) }

  describe '#add' do
    it 'adds two numbers and logs correctly' do
      expect(mock_logger).to receive(:log).with("The result of adding 2 and 3 is 5")
      calculator.add(2, 3)
    end
  end
end

在上述代码中，double('LoggerService')创建了一个模拟对象mock_logger。expect(mock_logger).to receive(:log).with("The result of adding 2 and 3 is 5")语句表示期望mock_logger的log方法被调用，并且传入特定的消息。如果Calculator的add方法在计算后没有调用log方法，或者调用时传入的消息不正确，测试将会失败。

伪造对象（Fakes）

伪造对象是具有真实实现的测试替身，但它们是为测试目的而简化或专门设计的。例如，假设Calculator依赖于一个数据库来存储历史计算记录。我们可以创建一个伪造的数据库类FakeDatabase来进行测试，它具有简单的存储和检索功能，而不依赖真实的数据库服务器。

class FakeDatabase
  def initialize
    @records = []
  end

  def save_calculation(a, b, result)
    @records << { a: a, b: b, result: result }
  end

  def get_calculations
    @records
  end
end

class Calculator
  def initialize(database)
    @database = database
  end

  def add(a, b)
    result = a + b
    @database.save_calculation(a, b, result)
    result
  end
end

# 使用MiniTest和伪造对象进行测试
require 'minitest/autorun'

class CalculatorWithFakeDatabaseTest < MiniTest::Test
  def test_addition_and_save_to_fake_database
    fake_database = FakeDatabase.new
    calculator = Calculator.new(fake_database)
    result = calculator.add(2, 3)
    assert_equal(5, result)
    calculations = fake_database.get_calculations
    assert_equal(1, calculations.length)
    assert_equal(2, calculations[0][:a])
    assert_equal(3, calculations[0][:b])
    assert_equal(5, calculations[0][:result])
  end
end

# 使用RSpec和伪造对象进行测试
require 'rspec'

describe Calculator do
  let(:fake_database) { FakeDatabase.new }
  let(:calculator) { Calculator.new(fake_database) }

  describe '#add' do
    it 'adds two numbers and saves to fake database correctly' do
      expect(calculator.add(2, 3)).to eq(5)
      calculations = fake_database.get_calculations
      expect(calculations.length).to eq(1)
      expect(calculations[0][:a]).to eq(2)
      expect(calculations[0][:b]).to eq(3)
      expect(calculations[0][:result]).to eq(5)
    end
  end
end

在上述代码中，FakeDatabase是一个伪造对象，它模拟了真实数据库的部分功能，用于测试Calculator与数据库交互的逻辑。

持续集成与TDD

什么是持续集成（CI）

持续集成是一种软件开发实践，团队成员频繁地将他们的代码更改合并到共享的主分支中。每次合并都会触发自动化构建和测试流程。其目的是尽早发现并解决集成问题，确保代码库始终处于可工作状态。

在Ruby项目中设置持续集成

常见的持续集成工具如Travis CI、CircleCI和GitHub Actions都支持Ruby项目。以GitHub Actions为例，假设我们有一个使用RSpec进行测试的Ruby项目。

  1. 创建.github/workflows目录 在项目根目录下创建.github/workflows目录。

  2. 编写工作流文件 例如，创建一个名为test.yml的文件：

name: Ruby Test
on:
  push:
    branches:
      - main
jobs:
  build:
    runs - on: ubuntu - latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Ruby
        uses: ruby/setup - ruby@v1
        with:
          ruby - version: 3.0.2
      - name: Install dependencies
        run: bundle install
      - name: Run tests
        run: bundle exec rspec

上述工作流定义了在每次推送到main分支时，从GitHub仓库检出代码，设置Ruby环境，安装项目依赖，然后运行RSpec测试。如果测试失败，GitHub Actions会在推送记录中显示失败信息，提醒开发者及时修复问题。

TDD与持续集成的协同作用

TDD编写的测试用例是持续集成的核心部分。通过持续集成，每次代码更改都能及时触发测试，确保新代码不会破坏原有功能。同时，持续集成的反馈循环促使开发者遵循TDD流程，先编写测试，再实现功能，因为只有测试通过才能成功合并代码。这种协同作用有助于提高代码质量，减少集成问题，使项目开发更加稳定和高效。

处理复杂场景下的TDD

处理依赖注入

在复杂的Ruby项目中，对象之间的依赖关系可能会变得很复杂。依赖注入是一种解决依赖问题的设计模式，它通过将依赖对象作为参数传递给需要它的对象，而不是在对象内部创建依赖对象。例如，假设我们有一个PaymentProcessor类，它依赖于CreditCardValidator和PaymentGateway类：

class CreditCardValidator
  def validate(card_number)
    # 实际的信用卡验证逻辑
    true
  end
end

class PaymentGateway
  def process_payment(amount, card_number)
    # 实际的支付处理逻辑
    true
  end
end

class PaymentProcessor
  def initialize(validator, gateway)
    @validator = validator
    @gateway = gateway
  end

  def process(amount, card_number)
    if @validator.validate(card_number)
      @gateway.process_payment(amount, card_number)
    else
      false
    end
  end
end

在测试PaymentProcessor时，我们可以通过依赖注入使用测试替身：

# 使用RSpec进行测试
require 'rspec'

describe PaymentProcessor do
  let(:mock_validator) { double('CreditCardValidator') }
  let(:mock_gateway) { double('PaymentGateway') }
  let(:processor) { PaymentProcessor.new(mock_validator, mock_gateway) }

  describe '#process' do
    context 'when card is valid' do
      before do
        allow(mock_validator).to receive(:validate).and_return(true)
        allow(mock_gateway).to receive(:process_payment).and_return(true)
      end

      it 'processes payment successfully' do
        expect(processor.process(100, '1234567890123456')).to be(true)
      end
    end

    context 'when card is invalid' do
      before do
        allow(mock_validator).to receive(:validate).and_return(false)
      end

      it 'does not process payment' do
        expect(processor.process(100, '1234567890123456')).to be(false)
      end
    end
  end
end

通过依赖注入，我们可以方便地使用模拟对象来测试PaymentProcessor的不同行为，而不受真实依赖对象的影响。

处理异步代码

在Ruby中，处理异步代码（如使用线程、纤维或async/await等）时进行TDD会有一些挑战。例如，假设我们有一个异步任务，它在后台计算两个数字的和，并在完成后调用回调函数：

require 'async'

def async_add(a, b, callback)
  async do
    result = a + b
    callback.call(result)
  end
end

使用MiniTest进行测试时，我们可以利用async - minitest库来处理异步操作：

require 'minitest/autorun'
require 'async/minitest'

class AsyncAddTest < MiniTest::Test
  include Async::MiniTest::Assertions

  def test_async_addition
    result = nil
    async do
      async_add(2, 3) do |sum|
        result = sum
      end
      assert_equal(5, result)
    end
  end
end

在RSpec中，可以使用rspec - async库：

require 'rspec'
require 'rspec/async'

describe 'async_add' do
  it 'adds two numbers asynchronously' do
    result = nil
    async do
      async_add(2, 3) do |sum|
        result = sum
      end
      expect(result).to eq(5)
    end
  end
end

这些库提供了在测试环境中处理异步代码的机制，确保我们能够对异步行为进行有效的测试。

测试遗留代码

遗留代码是指没有测试覆盖且难以修改的现有代码。在对遗留Ruby代码进行TDD时，首先要进行代码梳理，理解其功能和依赖关系。一种有效的方法是使用提取方法和提取类等重构技术，将代码分解为更小、更易于测试的单元。例如，假设我们有一段遗留代码：

# 遗留代码
def complex_operation(input)
  data = input.split(',')
  num1 = data[0].to_i
  num2 = data[1].to_i
  result = num1 + num2
  if result > 10
    'Greater than 10'
  else
    'Less than or equal to 10'
  end
end

我们可以通过提取方法来使其更易于测试：

def split_input(input)
  input.split(',')
end

def convert_to_numbers(data)
  data.map(&:to_i)
end

def add_numbers(num1, num2)
  num1 + num2
end

def evaluate_result(result)
  if result > 10
    'Greater than 10'
  else
    'Less than or equal to 10'
  end
end

def complex_operation(input)
  data = split_input(input)
  num1, num2 = convert_to_numbers(data)
  result = add_numbers(num1, num2)
  evaluate_result(result)
end

然后，我们可以分别对提取出来的方法编写单元测试：

# 使用MiniTest进行测试
require 'minitest/autorun'

class LegacyCodeTest < MiniTest::Test
  def test_split_input
    assert_equal(['2', '3'], split_input('2,3'))
  end

  def test_convert_to_numbers
    assert_equal([2, 3], convert_to_numbers(['2', '3']))
  end

  def test_add_numbers
    assert_equal(5, add_numbers(2, 3))
  end

  def test_evaluate_result
    assert_equal('Greater than 10', evaluate_result(11))
    assert_equal('Less than or equal to 10', evaluate_result(10))
  end

  def test_complex_operation
    assert_equal('Less than or equal to 10', complex_operation('2,3'))
  end
end

通过这种方式，我们可以逐步为遗留代码添加测试，并在必要时进行重构，使其更符合TDD的开发模式。