TDD stands for Test Driven Development. The notion was introduced back in the early 2000 by Kent Beck (1). In a nutshell, TDD is a practice whereby you write your automated tests first, in a way declare what you need and then write your actual code to fulfil the test. The practice forces you to write a failing test first, this test will introduce a new functionality that doesn’t exist yet, and by fulfilling the requirement you make the test pass. So, why is TDD so important?
It is still frightening how many development teams are not practicing automated unit testing integrated as part of their development process. Many reasons are given as to why it is a practice too difficult to follow or it doesn’t replace the human QA tester. In fact TDD can help in changing people minds and practices by telling a story, a story of how a piece of software is evolving and how to integrate the tests as part of writing the code. ‘Traditionally’ the developer would write some tests after completing the code, hoping to cover all the functionality. TDD changes our process by putting the tests first, so you don’t forget to do them and you have a test harness ready for any changes you make. It is bad practice to rely on another step in the process to clean up code. It is what we are trying to change here. TDD makes you think about your responsibility and take actions.
Like learning to play a musical instrument, it is the repeatable practice we follow every day that make us change our habits and make us a better musician, TDD makes us practice Unit Testing and forces us to become a better developers.
Refactoring may not seem as a direct connection but it is. Why do products stay behind with technology and find it so hard to move with changes? It’s the fear, the fear that they may change something that will break something else and bring customer systems down. They have a responsibility to the customer. When TDD is practiced, you can refactor. Changes can be made because all your code is tested and covered. Also, you have immediate feedback if you break something else and finally, you are encouraged to make changes in very small steps. Keeping each cycle compatible and not losing sight of your target and more importantly, where you came from. It is because your code is covered (I don’t mean code coverage which we will discuss in another blog) that you lose the fear. Every functional requirement is covered with a matching test, actually it’s the other way around; each functional requirement is covered with a working code to fulfil it. If you make changes to your code base, you know that no requirement is broken because you have all the tests to prove it is not.
If you look at the way teams are working traditionally, new functionalities are added to products (without refactoring) and are deemed safe because they never touch the product core, but in fact, they have no feedback if they break anything in the process at all, because they don’t follow any unit test practice they are still working in the dark, refactoring or just adding stuff, it is the same risk. Having a unit test harness and suite of tests is one of the most powerful places to be as a developer. With the knowledge you can fix issues with the design at any point in the cycle, you can refactor complete systems without breaking any functionalities. How many times have you said to yourself, “this product can be so much more if we make this small change, or if we could just add a service layer here… if we opened this as API?”.
Later in the week, we will continue our post on Why Test Driven Development is Essential, in the meantime, we would love to hear your thoughts on TDD.
continue reading part two