Test-Led Development is a flavour of Test Driven Development that focuses on productivity. This guide shows how it works, using Cucumber and RSpec as integration and unit test frameworks.

Hierarchical approach

Rails professionals since 2007

Our laser focus on a single technology has made us a leader in this space. Need help?

• We build a solid first version of your product
• We train your development team
• We rescue your project in trouble

Read more Show archive.org snapshot

Test-Led Development is a process with three abstraction levels:

• Integration test
• Code
• Unit level

During development you are frequently changing levels. It may look something like this:

Integration _                    ___
Code         \____    _____   __/   \__ ...
Unit test         \__/     \_/

Integration level

Start writing a feature file. List all usage scenarios you can think of:

Feature: <Concise description of the feature>

  <If it is a complex/questionable/very specific feature, add a motivation description or give a good overview.>

  Scenario: <Basic usage example, "happy path">

  # Add a scenario for each use case. Examples are: error behavior, access rights, contexts, closer looks at parts of the feature
  Scenario: ...

If required, add more feature files in the same manner. From these, the reader should understand everything to know about the new feature you're building.

When you're done sketching the feature, start writing out the scenarios one by one. Remember to document motivations or relevant context to a scenario if needed.

Once you are becoming unsure how a scenario will continue, it is time to turn to the code.

Code level

When starting to code, run the current scenario. Write the code that turns the scenario green.

As soon as you're about to write code that is not covered by integration tests, drop to the specs.

Examples include:

• a new service class
• a method with multiple code paths (if..else, case..when etc)

Unit level

Unit tests make sure some isolated code works as expected. For each method you're testing, start by listing all usage examples you can think of:

describe <class> do
  
  describe '<method>' do
    it '<basic usage example>'
    it '<other usage example>'
    it '...'
  end

end

From these, the reader should understand everything to know about that method.

When you're done listing examples, start writing them out. Write an example, then write the code to make it green. Iterate until all Specs are complete and green.

When you're done, return to writing the code. The specced thing now exists, so you can continue making that integration test green.