Since last one year I have started following TDD and I thought to share my early experience.
TDD, Test Driven Development, It is not only about testing before writing the code, it is the mindset. How well you know or understand the use-case you are going to implement. How clear you are on what you are going to write. How well do you understand the requirement and user’s expectation out of the piece of code you are going to write.
I have a failing test, now I know what I want.
In traditional way of developing software, we usually think that “I will implement it once it makes sense to me”. To get the sense out of any use-case you must understand it completely. First you understand the context and then you start writing code. Once you get the context it will start making more sense and you can connect the dots to see the big picture, you will deliver the quality software which will meet the expectations.
TDD is the best possible way I know to connect the dots and see the big picture before you write actual piece of code. It helps you to evaluate the gap between your understanding and actual expectations. First you understand the use-case. Then you write a test which will make sure the use-case should get delivered as expected. The test will fail initially since you don’t have any code to meet the expectations. Now the fun starts. Every piece of code you write will start making sense when you write it to make a test green. You will end up writing exactly what was asked and the test will make sure that expectations are delivered. It will also make sure that a functional bug or unwanted behavior won’t find an easy way to slide silently in your code.
It is essential to make a test fail. Sometimes it won’t even compile. But write it. Let it be ugly and let it fail. Once you have a failing test it will be very easy and straightforward to find what needs to be done to make the test green. The piece of code to make test green will evolve itself. But for that, you should have a failing test.
Once you make the test green, write the next test case for another use-case. Make it fail and write code for it. The cycle will go on so as your confidence about the code you are writing. Any unexpected code changes will be caught by a test. You don’t need to worry about regressions.
Well, these are initial thoughts. I am sure, I will discover more over the time and share it here 🙂
Please share your feedback/thoughts in comments section. Happy coding 🙂
Good One 🙂
Very well written Kishan! If you can add a simple example, that would be helpful for a reader to connect.
Thanks Pavan. Makes sense, will try to share example as well in upcoming articles around TDD 🙂