What are different shortcomings of test driven development?

The test driven development though touching a new high is not free of any drawbacks or short comings! It does have some short comings like any other software development process. 

The test driven development as we all know was considered to be somewhat similar to the test – first programming concepts of an agile software development process popularly known as the extreme programming or XP.

Because of all this, the test driven development methodology suffered a whole lot of criticism and so many of its short comings were discovered. 

Even after the test driven development process got its own individual standing in the line of the software development processes, the critics did not stop criticizing it! What were those short comings? 

Shortcomings of Test Driven Development

1. It is quite difficult to use the test driven development process in the situations and conditions where the success or failure of the software system, application or program is determined by the full functional tests. For example, it cannot be employed for developing the below mentioned things:

(a)    User interfaces

(b)   Programs that involve a data base in their working

(c)    Programs or applications depending up on some specific network configurations.

2. The software developers and programmers are encouraged to keep minimum possible amount of source code in to the software modules in the test driven development. On the other hand they are also encouraged to maximize the logic that lies in the library code which is testable. It encourages the use of the mock objects and fakes for the representation of the outside world.

3   3. The test driven development calls for an extensive need of the management support which is quite vital. The management may get a feeling of the wastage of the writing test cases since the entire organization is not in to the believing that the software product can be improved by the test driven development.

     

     4. The software developer who writes the code for the tests is the same one who is also assigned with the duty of the creation of the automated unit tests in the test driven development. Therefore a possibility that the same blind spot might be present in both the tests is induced which potentially endangers the stability of the software system or application. Both the produced test and code will be wrong!

    5. In test driven development process a false sense of security might be induced by a higher number of passing tests. This in turn will result in less number of additional software testing activities like compliance testing and integration testing.

     6. The tests created for the test driven development system themselves form a part of the maintenance over head of the software project. The tests which have been produced badly may include hard coded error strings which may make the whole test prone to failure are quite expensive when it comes to their maintenance. Such tests are typically fragile in nature.

    7. With the test driven development one risk is always there which comes from the ignorance of the regularly generated false failures. This causes the real failure also to be ignored and thus preventing its detection. Several methods have been developed to create tests which require low and easy maintenance. Creation of such test cases is considered to be a goal of the code refactoring phase of the development cycle.

     8. If you are following the test driven development, then it would be difficult for you to reproduce the level of coverage and testing detail achieved during the repeating test driven development cycles. Deleting those original tests can lead to undetectable holes in the test coverage.