An Aristotelian approach to trying out test-driven development
Raphael, School of Athens, fresco, 1509–1511
If you know about TDD you can jump introductions 😉
TDD is first of all a technique or practice for software development that postulates writing an automated test before any production code. There is a cycle of writing a failing test, writing the minimal code to pass the test, and then refactoring. This cycle is known as the red-green-refactor.
red-green-refactor cycle
Red
Create a failing test, and figure out what is needed, and what is not needed. We can lay out the requirements, and think if they make sense. We start to have a better understanding of the code we want to write and how we can approach it.
Green
Only implement a minimal code that makes the failing test pass.
Refactor
Where the design happens (Khalil, Solid book, 28 Test-Driven Development Workflow). We are in greenfield, we can move code around, remove duplicates, rename variables, split functions and so on. But we should not add new functionalities.
1 — Writing tests slows down the development process!
Writing tests may be slow in the beginning, but as soon as we start adding features to the codebase, tests will save us time because the feedback will increase our confidence.
2 — Writing tests first is not a good approach!
By starting with tests we are designing upfront, focusing on the requirements and the user point of view. We also get fast feedback, instead of changing the code, running the application, printing logs, debugging the code and staying awake all night, we can write the tests and let the tests speak.