TDD — Why is it important?
It’s your first time ever hearing of TDD and it’s from your professor. You were asked to implement TDD on a project and from the looks of it — you’re having a hard time doing exactly that. It bugs you how it take so much time writing a test prior to the coding solutions and makes you wonder why should you be doing this at all. Hence you came to this article expecting some skimming-through of TDD and its benefits, right? Don’t worry! We’re gonna do just that!
What is TDD?
As all of you may already know, TDD is a software development process that promotes writing tests prior to an implementation of a program. It serves as a tracking device that tells you the development progress of your software by knowing how many tests it has passed.
TDD is a software development process that tightly intertwine three main aspects of programming; coding, testing, and refactoring — and it has its own set of rules, which is :
- You may not write production code until you have written a failing test unit
- Write no more of a unit test than sufficient to fail
- Write no more production code than necessary to pass the failing test unit
Enough of the brief explanation, let’s now ask the question —
Okay, but why is it important?
Faster feedback, faster fix
Since TDD serves as a kind of feedback of the program you’re going to make, by the time the implementation process is finished, you will already have a feedback about bugs and such; which lines of implementation haven’t pass the failing test. This allows you to fix the code much more faster compared to when your test is made 1 month after the implementation is done. The rapid feedback alone offers you great advantages when developing a software.
Somehow guarantees that your program is of one vision with your product owner
That is to say you built the failing test around the acceptance criteria of your project’s user stories. By doing that and implementing TDD, you will know that when all of your test has passed or labeled as GREEN, it means your program has met the acceptance criteria of all the project’s user stories, all that is left is refactoring (and maybe some new tests if you’re going agile and in the brink of time was asked to change some features).
Doesn’t make you wonder ‘What am I doing again?’
Personally, when I’m creating a small project and decided not to implement TDD, I often forgot what it was I’m trying to implement; what function I needed to create. It’s because without TDD you basically only have a vague objective as to what the end result is going to be. TDD will offer you much clearer objective and guidance over what should be implemented on the program; what and how you should implement the functions and such.
Only needs you to implement A first rather than A, B, C, D all together
Developers tend to subconsciously take a big chunk of the application and just implement it. They tend to have a lot of functions to implement on their hands in one sitting, which then will leads to more bugs and of course makes their head goes bald. TDD will make the developer only focuses on one function at a time and on that slowly tackle the bigger picture, no stress attached.
Safe refactoring, cleaner code
After a failing test has been deemed success by a code you implemented, you will be on the step of refactoring. Refactoring asks you to make that mess of a code you already implemented to a more cleaner and readable one without changing the behavior of the code. So you can make the code cleaner without the need to write another test and some of your colleagues can read your code easier while your code still holds the same advantages of a TDD project.
Spend time now, save time later
TDD will cost you a lot of time and a lot of thinking. Implementing TDD will force you to brainstorm how your test is going to be made without even knowing how you’re going to implement the code. But then again — TDD guarantees a good code coverage. On post-implementation, TDD will save your time solving code bugs that are appearing over and over again just because you have little to no code coverage on your project.
Brain hurts, Need examples!
Sure! here is a simple example of TDD on my team project using Django and HTML. In this scenario I wanted to implement a simple landing page consisting of “HELLO WORLD” and a navigation bar.
RED
first of all, I implemented a UnitTest beforehand. 4 different cases of test regarding the landing page including a response test, a template test, and two component test — navbar and hello world.
Green
Once the test is red, time to implement the program. First, to pass the template test we need to create a template named “index.html”. And so we did :
Okay, now what we have to do is attached the template to django views for rendering and also implement routing to pass the response test.
That way, when the test is trying to get a response from “/” pass, Django will provide it, resulting in a 200 status code.
Lastly, to pass the component test we need to actually make the component on index.html including navbar and the HELLO WORLD encapsulated with h2 tag.
Now all we need to do is run the test again
Okay! now that we know it’s green, we need to crosscheck our codes to see if any of it needs refactoring. If it does, then do it without making the code goes RED again, that’s the point of refactoring after all.
Oh wow, TDD offers a lot of advantage!
Yeah, TDD is really really really— and I say — really important. When working on a big project, developers tend to be scared of progressing or changing their code because they wouldn’t want to create a butterfly effect that can mess up the whole project. TDD will keep you save from that very effect. It will provide you all of the advantages above and makes you feel safe, knowing that whatever it is that you’re trying to change on the code, the test will let you know whether you’re doing it wrong or not.
So yeah, about that project that was assigned by your professor — you should definitely implement TDD on it!
