I’m sure as developers we all must have faced situations when we have broken something in production that we’ve fixed with a hot-fix as soon as we can. How many times can we be certain that this hot-fix would not break any other feature? Anything done in a hurry could definitely mean we’ve missed out on something somewhere. What if there is a real process out there that could mean we can avoid all of this to a great extent?

What is TDD?

The Wikipedia definition of TDD says:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the code is improved so that the tests pass.

Simply put, test driven development is where we’d write the test cases first and then write the production code so as to pass the cases that were written first. It is a test-first approach in software development that could seriously save us a lot of last-minute bug fixing tensions.

With TDD it’s not promised that bugs would never occur again, it’s just that the chances of ever leaking out a show stopper bug are extremely close to zero. With TDD the test coverage of your application also would improve significantly which gives you an added advantage of having fewer production bugs.

Three laws of TDD

I recently got a chance to read the book — Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, in which three laws of TDD were mentioned which has to be followed. And I quote:

First Law — You may not write production code until you have written a failing unit test.

**Second Law — **You may not write more of a unit test than is sufficient to fail, and not compiling is failing.

**Third Law **— You may not write more production code than is sufficient to pass the currently failing test.

How does TDD make your life easy?

There are way too many benefits of writing your test cases first. Let’s consider how most developers would debug, say a bit of, JavaScript code. We might write a piece of code and reload it in a browser to check it. If you run into any nasty error, we’d check the console for it. JavaScript wouldn’t tell us what we did wrong for most parts, where our superhero console.log comes to rescue. I’m sure it’s console.log and browser dev-tools that saves every front end developer’s life at work. Until it works as expected, we’d mostly be doing — “Change-Compile-Reload” with a lot of breakpoints on repeat. Imagine how cool it would be if you don’t have to go through all of this just to check if you had written a piece of code right. TDD in this case could be the life jacket that could help you from drowning in a sea of errors.

#testing #programming #software-engineering #software-development #coding