There’s more in Test Driven Development than only automated tests
What is TDD ?
TDD is a software development approach where you make incrementally emerge code and tests at the same time. In the end, all the code that is being written, developed is covered by tests. It can be summed up by the repetition of this cycle red / green / refactor.
Here is how the cycle works for a given feature :
RED
- Start by writing a test that describes part of the behavior of the feature
- If you run the test, it will fail because the code hasn’t been written yet
- It’s the first part, make a failing test : RED
GREEN
- Write the minimum amount of code to make the test pass
- “Minimum” is key here, the code should grow incrementally by baby steps
- Thus it’s OK at this step to be quick and dirty, copy paste lines of code stack overflow etc
- Run the test, it must pass: GREEN
REFACTOR
- Now you have code that behaves as expected because it passes your test.
- If you change this code, you will see right away if it doesn’t have the behavior expected anymore thanks to the test
- Therefore, it makes you quite comfortable to improve its design without fearing breaking its right behavior : REFACTOR
At this step, you can use design patterns or any good practices of code design. Nonetheless, even if the refactor phasis is a little longer, it should not take too much time as this cycle is meant to remain quick and repeated many times. Of course, having been focused on incremental and baby steps makes this phasis shorter as well which is a good thing.
What it is not ?
TDD is often misunderstood ; these are two misconceptions about it.
Not a test first approach
A test first approach is quite different from TDD. For one feature or one technical component, you create all the test cases verifying its behavior before. Usually, it’s a senior member of the team that creates them so that a junior can have “safeguards” when he develops its code to check that it brings the right behavior.
Even if this approach can appear right on the paper, it has two important drawbacks :
First, it forces the senior developer to anticipate how the code should work beforehand with all the test cases. However, all the agile methodologies rely on this heavy assumption that it’s impossible, before writing code, to anticipate all the technical problematics you might run into.
Second, as the code and the tests don’t grow together simultaneously, the test use cases might be less fine-grained than what they would have been in TDD approach. Yes, you would have the validation of the expected behavior. But it might be harder to make emerge the right code for that, when TDD drives you all along the way with better-sized tests.
Behavior driven rather than technical driven
A second misconception makes tests focused not on behavior but on technical elements (classes, methods, functions). In this case, you would not be writing a test to validate a business behavior. You would be writing one test for one class or one test for one method.
The main drawback of this approach is that you couple your tests to the technical implementation of your software. This makes refactoring way more difficult : tests aren’t anymore a safeguard against changing how a component validates a functional behavior, it’s a safeguard against the current technical implementation of one given element. In the end, it makes it harder to change the business behavior of software, which makes it per se a bad approach because any proper software development methodologies aims at making software easier and not harder to change.
Two experts of TDD go further on that topic :
A famous reference on that by Ian Cooper, a TDD purist : TDD here did it all went wrong
Another reference by Valentina Cupac explaining the difference between the two approaches : TDD and clean architecture, driven by behavior
One obvious benefit : an automated test suite
The main benefit from having automated test suite is that, well, the tests are automated meaning they’re not performed by human. This brings three benefits :
- No schedule : tests can be run whenever you want by the machine
- No time limit : machines can repeatedly run test cases for long hours
- As many tests as you like : you can run tests in parallel on different machines which enables you to be way more exhaustive in your coverage
But there’s more than that !
1 : Always up to date documentation
Your tests constitute a “living documentation”, at any time, the behavior of the system is tracked in all the test use cases. Whenever the behavior changes, the tests change accordinly therefore it’s always up to date.
Therefore you don’t need anymore to plan retro-documentation session or create documentation US to track system’s behavior.
2 : A cleaner code thanks to a continuous and disciplined refactoring
As explained before, the inclusion of refactoring all along the TDD red/green/refactor cycles is extremely powerful. The code is continuously improved and refined which has a very high return on the long run.
Without that, refactoring is always deferred which results in a dirty codebase you have to clean every 3–4 years with a huge refactoring project.
3 : A decoupled architecture
TDD makes you focusing by design, on having small testable components. The only way to keep your tests simple is to have small decoupled components. As soon as components are imbricated and grow too big, it’s way more complex to test them. Therefore, TDD helps you get small decoupled components tested in isolation.
The benefits of a decoupled architecture are numerous, to name only a few: bugs are easier to localize, changes / bug fixes might not bring regressions at unexpected places, developments can be paralellized.
If you are interested in making making tech efficient with TDD, join us:
Interested about tech like us? Get in touch with us and stay tuned for more articles to come.
