Test Driven Development 🧪

I’m a big advocate for Test Driven Development and would highly recommend reading Kent Beck’s TDD by Example book to learn more about it. TDD is more than just testing, it is a process to drive the quality of code.

The main benefit of practicing TDD by the book is scope control.

• 🤩 Use the tests to drive the model and only write the code you need
• 🤩 You get a robust suite of tests describing the intended requirements meaning you can refactor with confidence
• 🤩 You have readable tests expressed against a usable interface because that was designed first

What is it?

TDD is a practice of taking requirements and writing code that implements those requirements.

The simplest way to explain TDD is the process of Red-Green-Refactor.

• Red - write a failing test for the next requirement
• Green - get the test to pass as quickly as possible, with the simplest implementation
• Refactor - apply patterns and best practices without needing to change the tests

Then think of the next test to make the implementation smarter, keep repeating til you can’t think of any more tests.

Following this practice is a change in mindset from thinking about the entities you might need, starting with the models and class structure then writing the tests to starting with the requirements, thinking about then interface you would like to work with and implementing the functionality you require.

Actually implementing the requirements is the easy bit.

The code is usable because the interface was designed first, you only write the code you need and you have a suite of tests describing all the desired behaviour you intended and wanted to keep.

Programmer tests

The tests you write for TDD are different to unit tests

wiki definition of a Unit and Programmer test:

Failure of a UnitTest shall implicate one (1) and only one (1) unit. (A method, class, module, or package.)

Failure of a ProgrammerTest, under TestDrivenDevelopment, implicates only the most recent edit.

With unit tests…

• Test coupled with structure of code
• Failure implies unit is broken
• Trigger for new test is a new method
• Tests will need to change during refactoring

With programmer tests…

• Test coupled with behaviour of code
• Failure implies last change is broken
• Trigger for new test is a new requirement
• Tests will not need to change during refactoring

Mocking

One of the big differences I have found with the result of unit testing and programmer testing is the approach to mocking.

Mocking can be great - it allows us to isolate tests and avoid calling slow or costly dependencies.

However it can cause issues if

• The tests are too coupled to the implementation, they can become hard to refactor
• The tests are actually testing mock behaviour, this can give a false sense of security

Some smells that you could be over mocking

• 👃 Reimplementing logic in tests
• 👃 Refactoring causes mocks/test logic to need to be moved around

When should we use mocks?

• ⭐️ Use mocks to isolate tests - test runs should not affect one another
• ⭐️ Use mocks to speed up test run - don’t call slow dependencies
• ⭐️ Use mocks for dependencies that could cause test failures

Mocking dependencies less reduces test refactoring costs

Refactoring

Refactoring is a specific technique based on behaviour preserving transformations. During refactoring the tests should not need to change and the system shouldn’t be broken for more than a few minutes at a time.

More information here.

Summary

Following TDD by the book you get the following benefits

• 🕵️‍♀️ Scope control - Only write the code you need
• 🧪 Suite of tests describing intended behaviour
• 📖 Readable tests against a usable interface
• ⏱ Quick feedback if anything is broken
• 🤝 A suite of tests you can trust - Believe that green test run means no issues
• 🏃‍♀️ Feeling of making progress, staying focused on task
• 📝 Define requirements before writing code

TDD is more than just testing, it is a process to drive the quality of code.