Agile & TDD go hand in hand…
Though it feels like I am many years late in writing this article but here I go with my thoughts…
How many of you have spent endless nights and weekends fixing Production bugs or deploying the newer version with failed attempts? Well, I would assume most of the developers around the world would be nodding.
I started my career with complex VBA macros and VB6 codes, and then moving on to VB .NET and settling down with C# for a while majorly among few other programming languages. I still remember the late nights working on Data Migration and Integration tools and programs when I used to run my code with no certainty whether it will bust into an error or pass. The errors used to be obscure, so at times after an hour you bump into something that gives you unpleasant result specially, the one team hated the most:
Oh come’ on why didn’t you handle it lazy …?? Chaos!!
The reality was that we all made such silly mistakes, sometimes it was due to hurry burry or sometimes it just happened!!
But many years ago, I was finally introduced to TDD: Test Driven Development and my whole experience with codes changed. At first, it wasn’t easy to indulge myself the TDD way because my mind and fingers were trained to do something that I used to call DDT -“Development Driven Test”.
Well in the beginning, I used to write the Test code but only after writing the actual logic or debugging the actual logic to some extent — “ Old Habits Die Hard”. I can assure you, it hasn’t been an easy journey to train my brain to accept the right TDD way. But as the saying goes, “practice makes a man perfect”, after few days, I had my breakthrough as slowly gradually I was able to think the Test code before writing the actual logic and could see the tests failing while validating the actual implementation. And I was able to continuously swap between Test and actual logic classes simultaneously.
Believe me, it is an experience and joy to be able to fix up to 50–60% of such silly errors that any developer can overlook. I am not saying that you would end up with a bug free code by using TDD but it will be much faster for you to fix the bug and re-deploy without worrying about such other bugs that you have already addressed in your tests (Referring to the Unit or Integration Tests).
Unit Tests?
In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.[1] — Credit https://www.wikipedia.org/
What is TDD?
Test driven development (TDD) is an software development approach in which a test is written before writing the code. Once the new code passes the test, it is refactored to an acceptable standard. TDD ensures that the source code is thoroughly unit tested and leads to modularized, flexible and extensible code. It focuses on writing only the code necessary to pass tests, making the design simple and clear. — credit www.techopedia.com
In a simple way:
A Valid Test: this does not only mean that your test should pass in the first go itself. No! a test becomes valid over the time, e.g. if it has failed in the beginning while you have been improvising on your actual code then you are on the right path. My suggestion is that never adjust or compromise with your actual code to make a test pass, I have seen new developers exploring TDD world making this mistake. It is very important that you are able to distinguish the difference between writing a Test code and Actual logic.
If you don’t know then FYI: we should Thank to Kent Beck for developing or re-discovering this software development process.
TDD is a behaviour that brings Freedom to the Team:
Yes, it’s not a joke! Who doesn’t want to learn & explore new things but you need time for that, Right?
You get more freedom by writing more Tests in your solutions. You can share the standard tests across team or get inspired of existing ones and this way you encourage re-usability and refactoring. Such tests also enable you to deploy faster (with less worries). A well written code having high code coverage reduces the chances of failed deployments.
I still remember one of my colleagues who used to bite his nails before checking in his code and worried about messing up the final build, but today with features like gated check-in, continuous integration and continuous deployment (where these Unit and Integration Tests would be executed first), one can be assured that his/her code has been validated and would not be allowed to merge to the branch if it fails. Peace of Mind!! When you get freedom from your daily stuff, you could invest your time in exploring newer technologies, trying out new patterns and improving your code quality.
Agile and TDD go hand in hand
Well, someone once asked me, why do I always say this? The answer is very simple, since you have limited time during every iteration, so my counter question would be: Give me another option which could ensure the quality of my team’s code, which enables me to discover errors and fail fast and help me in deploying fast or on demand every sprint with ensured quality (be it 1 week or 2 weeks sprint or more).
To me TDD can directly be related to the Agile Manifestos i.e.: Working Software & Responding to change. In agile world we thrive for continuous feedback from our customers and users or team itself Right? Let me tell you TDD brings that feedback through the unit tests.
So, it is very simple, TDD enables scalability for products and allow Agile team to develop new functionalities faster, better and deliver the end product with high quality. Faster: The concepts like mocking allows developers to develop their part independently without relying on readiness of specific database or dataset or dependent API or any other integration component.
It also helps in on-boarding new team members. As, for some developers, I have seen that a well written Test code with some minimal documentation helped them in on-boarding themselves on the team.
To conclude: Agile & TDD — A Mindset More Than Methodology & Process which evolves over time.
So, my question is: Are you or your organization is moving towards becoming AGILE? If so, are you encouraging your Development Teams to thrive for TDD?
Leave your thoughts behind!! :-)
