Test-Driven Development (TDD) in its most dogmatic form (red-green-refactor in micro-iterations) can be tedious. It does not have to be this way! This guide shows a pragmatic approach with integration and unit tests, that works in practice and improves on productivity.

Advantages

No added effort: tests need to be written anyway.
Test heads serve as todo lists. You'll always know what is finished and what is left to do.
Big tasks are broken down into smaller tasks that can be processed one by one.
You will not forget a test.

The flow of TDD

Write a feature file and list all relevant scenarios. Just the titles.
Fill the scenarios with your expectations, one by one. When in doubt about the final behavior, you may switch to the code (3) at any time.
Make the scenarios green one by one. When writing code that is not covered by the integration tests, add unit tests (4).
Add a unit test and list all relevant examples
Fill the examples with your expectations & implement them, one by one.

UI/UX Design by

We make sure that your target audience has the best possible experience with your digital product. You get:

Design tailored to your audience
Proven processes customized to your needs
An expert team of experienced designers

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: ...

(This example uses Cucumber, but the approach works with any integration testing framework.)

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. Remember to finish the test before starting work on the next.

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:

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

(This example uses RSpec, but the approach works with any unit testing framework.)

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.

Hierarchical approach

TDD with integration and unit tests is a process with three abstraction levels:

Integration level
Code
Unit level

Integration tests give the code its rough form, whereas unit tests pinpoint selected behavior.

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

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

References

In his article on Canon TDD Show archive.org snapshot , Kent Beck (who originally coined the term "TDD" in the late 90s) summarizes the key aspects of test-driven development.

Test-Driven Development with integration and unit tests: a pragmatic approach