Do You Still Have Doubts About TDD?

Why should you always follow TDD?

Test-driven Development is a mindset. The idea is to write unit tests first and actual code later. Your test cases should drive your code not the other way round.

Test-driven Development

As shown in the above cycle, when you first write the unit test, your test case will fail as there is no code. Then you write the code and run the test cases. This time it shall pass, if not, fix your code and re-run the tests again. Once all tests pass, you can refactor or beautify the code confidently as you know if something breaks your test cases will fail.

Pros of TDD:

• Bug-free Code: Unit tests are initially written based on the requirements. Once your unit tests pass, you will know that your code is ‘bug-free’.
• Confidence in Refactoring: Let’s say while going through a project, you feel that one piece of code can be written in a better way. You will be confident to take up that refactoring task, if there are already proper unit tests for that code. Otherwise, you will never know that your refactoring will break any business logic.
• Documentation in code: You can understand all the features of a particular file by going through the unit tests. From there you will be able to grasp what the code is intended to do.
• No Regressions: As you have more than 90% coverage of your code by unit tests, the chances of any regression is very low. Failing unit tests will identify any new change which is breaking the existing features.
• Fail Fast: It’s always better to be aware of bugs in your development cycle than in production. Unit tests enable you to identify new bugs from code, in the development phase only.
• KISS: TDD helps developers to Keep it Simple and Stupid. As the unit tests are very close to the core code logic, the code you are writing will be simple and modular.

How to enable your team toward TDD?

• It’s all about mindset. When you are in danger, you do not change your mindset necessarily. Similarly, in a fast delivery environment, you should not move away from TDD. Because if you do not implement TDD, then eventually it will slow you down in the future. So try to cultivate this mindset in your team.
• Use Junit and Mockito frameworks to write clean and modular unit tests.
• Use code quality tools like SonarQube, which will keep a report of the unit tests coverage of your project.
• Integrate code check plugins with your pull requests, so that you will get a report on raising a PR. The developer and the reviewers will know the coverage of the new code added as well as the existing coverage.
• In IDEs like Intellij and Eclipse, you will get the option to run the unit tests with coverage. IDE will mark the covered and uncovered sections of your code with Green and Red colours.

What is the difference between a dummy test case and a proper test case?

Let’s say we have the following feature as a requirement:

Dummy Test case Example:(What NOT to do!!)

Even though you do a subtraction instead of addition in your code, your test case will always pass. There are no assertions of the result. These types of unit tests will increase your code coverage without actually testing your code.

Do not just write tests to increase your coverage!!

Ideal Test cases for the above feature:

Ideally, any logical change in your code should break the existing test cases

To conclude, the only way to keep your code clean, modular, maintainable, and future ready is by Test-driven Development.

Do you still have doubts about TDD? Write to me your use cases and I will explain why you should use TDD.