TDD (Test-Driven Development) Introduction
I’m going to give an introduction into what TDD is and what it consists of, based on Kent Beck’s Test-Driven Development by Example book.
Clean code that works is a worthwhile goal for a whole bunch of reasons
Using clean code helps a lot in many ways when you are developing:
- You develop in a predictable way (easy to think of and easy to code) and don’t have to worry about a long list of bugs yet to appear because you will avoid most of them and also detect quickly the ones that exist because of clean code rules.
- You learn a lot in the process about clean code and how things should be programmed and also are open to new solutions that work better than the one you are implementing because of the refactor step.
- It makes developers lives easier and also your team will trust your way of coding and they will count on you because they will know that not many bugs will appear and that everything you code will be easy to fix thanks to the way it is organized.
- Also, but most importantly, it feels good to write it.
TDD with clean code
Many times when we want to implement clean code, there are a lot of forces that push us apart from its track. But there is a way we can implement clean code and follow a certain development methodology. We will drive development with automated tests, this is called Test-Driven Development. What this states mainly are two rules: that we write new code only if an automated test has failed and eliminate duplication.
Two simple rules, a bunch of complex individual and group behavior with technical implications
Although there are only two rules, a lot of things relate from this rules. We must design organically, with running code providing feedback between decisions. The tests must be written by ourselves during this process, so it is a test and develop process. The environment should provide rapid response to any change even if it is small. The design must consist of many highly cohesive and loosely coupled components.
Task order in TDD
- Red: Write a small test that doesn’t work or even that it doesn’t compile.
- Green: Make the test pass no matter what, just make it work. Literally.
- Refactor: Eliminate all the duplication used to make the test pass.
Red/Green/Refactor — This is the TDD mantra
What does TDD brings to the software development industry?
Since the defect density can be reduced by a lot, QA can shift from reactive work to proactive work. Project managers can estimate their projects better because not many nasty surprises will appear and can also involve real customers in daily development. Software engineers can collaborate in minute-by-minute instead of daily or weekly. And finally, this will give us the perk of being able to ship new software every day with no trouble.
TDD is a pretty extensive and not easy extra work for a developer. So, why would a developer do all this extra work and produce code in tiny steps instead of doing giants jumps during this process? The answer is courage.
We need courage in programming to avoid fear. Fear is really bad in the programming world because it makes you communicate less, shy away from feedback, grumpy, tentative, etc. All of these things are horrible for us programmers. With courage we can learn to tackle these things and get the most out of the software, design and ourselves. And TDD will help us with all of this. Except grumpiness, you need to work on that one on your own.