A practical introduction to Test Driven Development (TDD): Part-1
Have you ever come across a situation where you felt that the code you wrote was at excellent production quality level?
If yes, then definitely you would have come across a situation where the code you wrote produced excellent bugs in production.
If you are feeling connected, then this article is for you.
Have you ever wondered/pondered?
Why is that you were able to write excellent production quality code in certain modules/products?
VS
Why is that you wrote a code in certain modules/products which were full of bugs?
Think through……
Well we will be able to reason it out for many common factors such as:
- I did a POC and that POC code was pushed to production.
2. There was time constraint/pressure.
3. I did not understand the requirement correctly.
And so on.
Well if you are a developer by heart, then you know that there is 1 major reason why you wrote a code which performed so well in production without major bugs.
The reason is:
1. Your code was able to handle most of the corner/edge scenarios.
Then comes the next question.
What happened to the production quality code which you wrote after a few months? (Assuming that there was active development in the module/product).
Did it remain bug free even after numerous changes to the module/product?
If the answer is “Yes”, then you know that it was because of the rock-solid unit tests which you had written for that module/product.
If the answer is “No”, then you know that it was because of not having unit tests which tested the functionality of the code rather you might have had unit tests just for the code coverage numbers.
So, let us summarize what does it cost for business/organizations who are heavily banking upon software for their success.
Scenario 1: “Having rock solid unit tests for the code”
1. Feature development will be faster.
2. Feature development across teams will have a predictable cadence.
3. Less bugs in production.
4. Developers will have the confidence to refactor the code.
5. The codebase will be agile, any changes requested will take less time.
6. Teams will be truly agile in terms of software development, delivery.
7. Fosters “Team and Technical agility” across teams.
8. Product delivered will be of high quality.
9. Business/Organizations will be able to take the product much faster and with higher quality to the market.
10. Business/Organizations succeed in their mission and vision.
Scenario 2: “Having unit tests just for the sake of code coverage numbers”
1. Feature development will be slower.
2. Feature development across teams will not have a predictable cadence.
3. More bugs in production.
4. Developers will not have the confidence to refactor the code.
5. The codebase will not be agile, any changes requested will take more time.
6. Teams will not be agile in terms of software development or delivery.
7. Teams will lack in “Team and Technical agility”.
8. Product delivered will be of substandard quality.
9. Business/Organizations will struggle to take the product on time to the market.
10. Business/Organizations will struggle to deliver a quality product.
When we know what it takes to build a production quality code, then why is that most business/organizations are struggling to maintain their “Team and Technical Agility”.
The reason is obvious, writing rock-solid unit tests which tests the functionality along with the development cycle is the trademark quality of good software developers.
Good software developers are very hard to find!!
Is there any magic bullet for this problem?
Yes, by following Test Driven Development, TDD ensures/enforces rock-solid unit tests during the development cycle which in turn ensures “Team and Technical Agility” which in turn ensures “Business Agility”
In the upcoming articles + video sessions around TDD, I will cover the below topics:
1. How to start with TDD.
2. Tools and Frameworks to support TDD.
3. Practically implementation of TDD using a real-world business problem.
4. How TDD ensures rock-solid unit tests.
5. Practical challenges in implementing TDD.