TDD

In Traditional development approaches, errors are found at the build stage or when the software is being used by the end-user, which is a drawback. TDD is used to overcome this.

What is TDD?

TDD stands for Test-Driven Development which is a programming practice that instructs developers to write new code only if an automated test has failed. This avoids duplication of code. Test-Driven Development starts with designing and developing tests for every small functionality of an application.

You can see the steps of TDD in the following figure:

Why TDD?

· TDD Eliminates fear of change: If a code change introduces a bug, developers are alerted to it quickly, and TDD’s tight feedback loop will quickly notify them when it’s fixed.

· TDD has a safety net: which makes continuous deployment safer. Test failures halt the deployment process, allowing you to fix bugs before customers ever have the chance to see them.

· Fewer bugs: TDD practitioners release fewer bugs because code is constantly tested and refactored throughout the development process.

· Faster developer feedback loop: Without TDD, developers must manually test each change to ensure that it works. With TDD, unit tests can run on-change automatically, providing faster feedback during development and debugging sessions.

Three laws of TDD

• Law 1: You can’t write any production code until you have first written a failing unit test pass.
• Law 2: You can’t write more of a unit test than is sufficient to fail, and not compiling is failing. This means, start your tests small, then work your way up.
• Law 3: You can’t write more production code than is sufficient to pass the currently failing unit test.

My Experience with TDD

In the past, I didn’t think about the necessity to write failing tests and then start refactoring so that my code meets my goals. For example, a picture that time when you finish a code sprint and you have pushed all your working code after some time you test again and codes are not working anymore. At first, you think it’s a simple bug that can even be solved in an hour, but you end up spending the whole night.

I believe using TDD will save you a lot of time by not doing a lot of manual testing each time you made a change to your code. The test will do the compiling for you and immediately tells you why it’s failing. Using the TDD approach can allow you to dictate how you want to see the response from the server and then writing and rewriting the code to make it pass.

TDD is not easy in development and it takes time to finish a certain task compared to coding straight, but it’s more efficient. For me, TDD is far more than a safety net. It’s also constant, fast, and real-time feedback. Instant gratification when I get it right. Instant, descriptive bug report when I get it wrong. I see the TDD approach very beneficial to helping entry-level developers become better developers and I will make my best effort to continue using TDD in my projects.