In this strange year, at the end of the summer, I decided to change my work experience. I had some new ambitions and a willingness to learn new things and improve others. One of the things I wanted to improve is unit testing, an argument that I couldn't practice in my past jobs, so I started to search for a new experience.
After some job interviews, I made my decision, and in mid-November, I started my new experience.
In the first period, my time was divided in half between work and study.
The study was divide into two sections: corporate culture and technical culture.
Today I want to write some thoughts about a single point presents in the technical culture: Test-Driven Development (TDD).
What is TDD?
Test-driven development is a software development process relying on software requirements being converted to test cases before the software is fully developed, and tracking all software development by repeatedly testing the software against all test cases.
For more developer is only a process known as "write tests before your code" (also for me until recently)
The method bases its power on a simple repeatable flow "Red Green Refactor". In the red step, the developer must write the test for the next development feature; obviously, this test the first time fails because the code isn't present. In the green step, the developer must change the test spy from red to green with the minimum code possible. In the Refactor step, the developer can improve, review and organize the code if it's necessary.
My study about TDD
Before starting my new work experience I had read some articles about this topic and a famous book known as the guide of the method Test Driven Development. By Example, the author is Kent Beck, I think introductions are unnecessary.
The book is very interesting and illustrates how to implement the method in the best way. It explains the bases of the method, it illustrates how to implement the method and it shows some best practices to improve the implementation during our work.
After this reading, I had to try to implement this method in my daily work but with greater difficulty, I didn't understand why but for me TDD started to be a difficult methodology to implement in my daily work. The time spent implementing the method reduced my productivity drastically and the time to release the new feature increased, so I decided to put it aside (I'm talking about the period before changing my job).
TDD after changing my job
During my onBoarding, as I said before, I spent some time studying and practicing TDD. In this period I approached the method from a different point of view: Agile.
Agile is a practice that I studied much during my school period but I couldn't implement it in my previous jobs.
So I started to change my mind about TDD, from "write tests before typing code" to "write the business requirement before typing the implementation". This new approach helps me to move my development from the output to the outcome and improves my velocity to implement the TDD method. Before this approach my mind spent too much time to discover all the possible failure of the code before start implement the feature, now my mind spends the right time to write the outcome of the code and after that, I type the code to change the test spy from red to green and then I refactor the code to review or organize it. Only after that, my mind spends not too much time to add tests that represent the extreme cases and if necessary I refactor the code to pass these cases as well.
Writing my tests by basing them on the outcome instead of the output changed also my idea about the TDD method, it's a powerful tool to improve our velocity and the consistency of our code. It helps us to rest assured during refactoring, it helps us to be sure of the delivery code, and our outcomes respect the business requirements.
The flow "Red Green Refactor" followed by us during the development helps us to follow the correct way and leave our mind free to create new features, when we break something the test suite notify us and we can fix the error before this goes live.
Conclusion
TDD is a powerful method for me and I think also for thousands of developers in the world. In my opinion, in an agile context, but not only, it's an extraordinary tool to improve the confidence of the code but also to create powerful outcome documentations. It helps developers to think about the outcome of their work before typing a single raw of code, it helps them to write their code without fear of breaking something else, and I think these pros are not limited to developers but these are pros also for the stakeholders, the sponsors and all the members of the project.
It's a powerful tool also to have continuous feedback from our code, it helps us to stay confident and review our code in serenity.
Also, it helps us to increase our team with new developers because if a development breaks the code outcome the test suite notifies us and we can fix it quickly.
Top comments (0)