TEST DRIVEN DEVELOPMENT

Test Driven Development (TDD) is software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and making code simple and bug-free.

Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD instructs developers to write new code only if an automated test has failed. This avoids duplication of code. The full form of TDD is Test-driven development.

The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need to test to fulfill them).

Advantages of TDD

• Early bug notification.

Developers test their code but in the database world, this often consists of manual tests or one-off scripts. Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will.

• Better Designed, cleaner and more extensible code.

It helps to understand how the code will be used and how it interacts with other modules.

It results in better design decision and more maintainable code.

TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities. This makes the code simpler to understand.

TDD also forces to write only production code to pass tests based on user requirements.

• Confidence to Refactor

If you refactor code, there can be possibilities of breaks in the code. So having a set of automated tests you can fix those breaks before release. Proper warning will be given if breaks found when automated tests are used.

Using TDD, should results in faster, more extensible code with fewer bugs that can be updated with minimal risks.

• Good for teamwork

In the absence of any team member, other team members can easily pick up and work on the code. It also aids knowledge sharing, thereby making the team more effective overall.

• Good for Developers

Though developers have to spend more time in writing TDD test cases, it takes a lot less time for debugging and developing new features. You will write cleaner, less complicated code.

Disadvantages of TDD

Just like everything else in the world, TDD has some disadvantages. The main ones are:

• No silver bullet: Tests help to find bugs, but they can’t find bugs that you introduce in the test code and in implementation code. If you haven’t understood the problem you need to solve, writing tests most probably doesn’t help.
• It seems slower at the beginning: If you start TDD, you will get the feeling that you need a longer duration of time for easy implementations. You need to think about the interfaces, write the test code, and run the tests before you can finally start writing the code.
• All the members of a team need to do it: As TDD influences the design of code, it is recommended that either all the members of a team use TDD or no one at all. In addition to this, it’s sometimes difficult to justify TDD to the management because they often have the feeling that the implementation of new features takes longer if developers write code that won’t end up in the product half of the time. It helps if the whole team agrees on the importance of unit tests.
• Tests need to be maintained when requirements change: Probably, the strongest argument against TDD is that the tests have to be maintained as the code has to. Whenever requirements change, you need to change the code and tests. But you are working with TDD. This means that you need to change the tests first and then make the tests pass. So, in reality, this disadvantage is the same as before when writing code that apparently takes a long time.

How to perform TDD Test

Following steps define how to perform TDD test,

1. Add a test.
2. Run all tests and see if any new test fails.
3. Write some code.
4. Run tests and Refactor code.
5. Repeat.

TDD cycle defines

1. Write a test
2. Make it run.
3. Change the code to make it right i.e. Refactor.
4. Repeat process.

Some clarifications about TDD:

• TDD is neither about “Testing” nor about “Design”.
• TDD does not mean “write some of the tests, then build a system that passes the tests.
• TDD does not mean “do lots of Testing.”