It’s a design practice that focuses on creating tests before developing the actual code.
TDD is not only about unit tests.
TDD is an evolution of test first principle.
The goal is clean code that works.
Rules
- Write a failing automated test before you write any code.
- Remove duplication.
Benefits
- Helps us to write just enough code that satisfies the requirements (represented as tests). That way we don’t overengineer our solution and we don’t make a big design up front.
- Provides a quick feedback on the design, simplicity and maintainability of our code.
- Provides a living and executable documentation of our application.
- Rich suite of regression tests.
- Manage fear during development, because we can tackle big problems in small increments and get a feedback for each step.
TDD cycle: RED, GREEN, REFACTOR
-
Write a failing test (RED). Write a test that describes some requirement of the software. Execute the test and watch it fail. If it doesn’t fail, then it’s an unnecessary test.
-
Make it pass (GREEN). Make the test green by writing the simplest production code that will work.
-
REFACTOR. Don’t rush to the next feature. Slow down and make your code (both production and test code) as clean as it can be.
-
Write a test. Think about how you would like the operation in your mind to appear in your code. You are writing a story. Invent the interface you wish you had. Include all of the elements in the story that you imagine will be necessary to calculate the right answers.
-
Make it run. Quickly getting that bar to go to green dominates everything else. If a clean, simple solution is obvious, then type it in. If the clean, simple solution is obvious but it will take you a minute, then make a note of it and get back to the main problem, which is getting the bar green in seconds. This shift in aesthetics is hard for some experienced software engineers. They only know how to follow the rules of good engineering. Quick green excuses all sins. But only for a moment.
-
Make it right. Now that the system is behaving, put the sinful ways of the recent past behind you. Step back onto the straight and narrow path of software righteousness. Remove the duplication that you have introduced, and get to green quickly.
In pure form of TDD you are never more than one change away from a green bar.
Why
TDD is a way to manage fear during programming.
It allows us to work in smaller steps. Not necessarily all the time, but when we are feeling a little unsure, we can switch to a lower gear, and similarly take a bigger steps when smaller ones feels a little bit restrictive.
Triangulation
Only generalize the code the code when you have more than one example, and only when the second example demands a more general solution.
- Tests should run fast. Instant feedback.
- Isolate tests. Order independent.
- Implement tests one by one. With each test new tests (requirements) will appear. Keep them in a backlog. Don’t try to implement all at once.
Workflow
When to test?
Test first. It will become a method for scope control and will keep stress level in check.
When to assert?
Assert first. Start writing tests with assertions. It will help deciding the naming, where methods belongs, are new methods/class needed, what it the right answer etc.
Which test to pick next?
Pick a test that will teach you something and that you are confident you can implement.
Each test should represent one step toward your overall goal.
Known-to-unknown.