ITGumbo: spicing IT up

The SDLC practice is that when a code line is changed all unit and feature tests that would execute this code line are run to confirm that the change does not fail any test. The TDD practice is, if a test fails check the code line and rework it to ensure that the test case pass; this may affect other test cases also. In the given figure if traditional development method (waterfall model) is used, functions will be written after feature design and then features are tested, if a common function is fixed for a bug all the effected features are tested. In traditional development writing test cases and functional code are two independent processes that may be executed in parallel or any order. In TDD these two processes are sequential, i.e. functional code is written after test cases are written. In both methods if a function is common to the two test cases any change in the function must still ensure that all test cases pass. It can be concluded that TDD method is being used to derive concrete requirements for code writing from abstract design. Or, TDD method is being used to involve programmers who do not have sufficient experience to transform design into code.

It is suggested that TDD tests every single line of code whereas traditional testing does not guarantee this. This may not be true, code coverage tools can be used to ensure that all code is tested and redundant code is deleted. It is suggested by Kent Beck that TDD is a method that will enable any developer to write code. However, it appears that TDD is a method that is being used to resolve the time requirements of SDLC phase, to reduce management overhead by avoiding difficult SDLC processes, to reduce product development costs and to take advantage of pool of programmers. TDD is a method that is being used to encourage testing. The drawback of TDD is the iterative procedure involved as compared to the SDLC waterfall model. In an outsourcing era the success of the project is determined by the agreement between the two teams (outsourcer and contractor) on the understanding of the contract artifact, this may be the project requirements document or design document. Here TDD may be a good practice to ensure contractors understand the contract artifact, because changes to the artifact are not allowed. But to suggest that TDD is a good practice to evolve requirements or design document is not correct. However, it is very often used in the requirement analysis or design phase to develop a prototype to confirm the feasibility of requirements or design before the implementation starts.

In this article Boby George and Laurie Williams have presented experimental data on TDD practice in the software industry. There findings are:

1. TDD approach yields superior code quality.


2. TDD approach takes more time.


3. TDD approach improves programmer's productivity.


4. TDD approach facilitates simpler design.

The arguments to these findings are:

• If a modular design can give the function algorithm then it is a better practice to write the code and test it for complete functionality rather than updating function code for every test case. Example: switch statement. Code writer always spends some-time on self code review; if the function design is present some level of unit testing is done in human brain.


• Test cases are to be written irrespective of TDD approach, therefore cause for time taken can not be attributed to writing test cases, more time is required because of the need to update the function code for every test case and this may result in code restructuring, hence additional testing.


• As mentioned earlier TDD can enhance programmer understandability, therefore this approach may be good where designer and programmer are different humans. TDD is a way of asking the programmer if he/she understands the design.


• TDD cannot always be used for better design, if experienced designers are present TDD may not be required and waterfall model is suitable.

It can be concluded that TDD is another SDLC model that may be used with discretion based on project circumstances.