NATIONAL INSTITUTE OF INDUSTRIAL ENGINEERING

PGDIE-42

By: -

 

RATIKA KAPOOR
Roll NO. 75
K.RATNAKAR REDDY
Roll No. 112
YOGESH BHONDEKAR
Roll No. 105

Test-driven development (TDD) of software systems

Introduction

Test driven development (TDD) is a software engineering technique to promote fast feedback, task-oriented development, improved quality assurance and more comprehensible low-level software design. Benefits have been shown for non-reusable software development in terms of improved quality (e.g. lower defect density)

Test-Driven Development (TDD) is a novel approach to software engineering that consists of short development iterations where the test case(s) covering a new functionality are written first. The implementation code necessary to pass the tests is implemented afterwards then tested against the test cases. Defects are fixed and components are refactored to accommodate changes. In this approach, writing the code is done with a greedy approach, i.e. writing just enough to make tests pass, and the coding per TDD cycle is usually only a one-to-atmost-few short method, functions or objects that is called by the new test, i.e. small increments of code.

Test-Driven Development can be implemented at several levels:

• Basic cycle which covers the generation of unit test cases, implementation, build and refactoring.

• Comprehensive development process which extends the methodology to overall black box testing scripts, including performance, scalability and security testing.

• Agile process such as SCRUM

Benefits and Limitations

There are several benefits to have the test cases written before the production code

• The engineer(s) have almost an immediate feedback on the components they develop and tested against the test cases. The turnaround time for the resolution of defects is significant shorter than traditional waterfall methodology where the code is tested days or weeks after implementation and the developer has moved to other modules.

• The implementation is more likely to match the original requirements as defined  by product management. The test cases are easily generated from the use cases or user scenario and reflect the functional specifications accurately without interference from the constraints and limitation of the architecture design or programming constructs. The approach guarantees to some degree that the final version fulfill customer’ or product marketing requests.

• The methodology prevents unwarranted design or components to crimp into the product. The test cases or unit test drivers define the exact set of required features. It is quite easy to identify redundant code, detect and terminate unnecessary engineering tasks.

• The pre-existence of test cases allow the developer to provide a first draft of an implementation for the purpose of prototyping, evaluation or alpha release, and

postponed a more formal implementation through refactoring.

• TDD fits nicely into customer-centric agile process such as SCRUM. For instance, the sprint phase can be defined as the implementation of functionality to execute against a pre-defined set of test cases instead of the more traditional set of specifications or problem statement.

• TDD can lead to more modularized, flexible, and extensible code. The methodology requires that the developer think of the software in terms of small units that can be written and tested independently and integrated together later.

Basic TDD Cycle

Unit Test Drivers

The most primitive cycle for TDD involves the automation or semi-automation of the generation and execution of unit test drivers. Programming language such as Java, C++ and Perl as well as IDE such as Eclipse or Visual Studio provide support for integrating unit test frameworks.

Fig. 1 Representation of Basic TDD Cycle

The key tasks in the TDD methodology are:

1. Product management defines the new features or improvement to implement

2. Architect or senior developer define an interface (declarative) that fulfill the use case

3. Engineers create a unit test driver to test the feature

4. Engineers implements a first version which is tested against the test driver

5. The implementation is subsequently refined then re-tested incrementally

6. At each increment engineer(s) may upgrade the original design through refactoring

Automation

One well documented concern regarding this methodology is the effort and cost required to create detailed unit test code. Consequently, a commitment to automate part of the unit testing cycle is essential to the overall adoption of TDD.

The two key elements of an automated TDD strategy are:

• Automated test generation: The team should investigate and adopt framework or IDE that support the generation of unit test code from a declarative interface

• Automated test execution: The test code should be automatically compiled and executed as part of the build and regression test process.

Extending the TDD Process

Product or System Testing

Most of TDD practitioners focus on unit test driver with or without automation. However, the concept can be extended to product testing as long as interfaces are clearly defined and a test scripting engine is available. The engine should be able to generate sequence of actions or traffic which simulates the user interaction with the overall product or any of its components such as GUI, database or web servers.

The typical client test engine generates:

o Graphical actions and events through a record and replay mechanism

o Command line request

o SQL, HTTP or TCP traffic or packets

Fig. 2 Representation of Extended TDD Process

Here are the steps:

1. Product management defines the new set of features or improvement to implement

2. Use cases are created to describe the basic sequence

3. Architect specifies the set of programming or graphical interface functions

4. QA engineers rely on use case to create test cases and test scripts

5. Unit test drivers are created from the user cases and programming interface

6. Engineers implements a first version or draft which is validated (failed in the first couple attempts) against the test scripts and unit test drivers

7. The implementation is incrementally refined and re-factored as necessary

8. The product is then tested against the test scripts following the integration phase.

Refactoring

Refactoring is a key element of any agile process including TDD methodology. A trend analysis of the evolution of the design and implementation through successive refactoring iteration may give a hint on the probability to reach a stable architecture or component. It is quite conceivable to add design review of the component design during the development cycle to evaluate the stability of the implementation.

Integration with SCRUM

Test Driven Development is the greatest asset to come out of the agile movement. Significant quality and productivity gains are made by using TDD. Hence it is very rapidly spreading through development circles. However, the engineering teams who already practicing agile process such as SCRUM need to reconcile their existing practice with TDD.

By providing a framework to automatically validate incrementally production code against predefined unit test drivers, TDD allows to extend the purpose of sprint as converging the implementation to pass the test harness and add critical quality metrics (ratio of code coverage and passed test) to the monitoring dashboard.

Fig.3 Overall SCRUM agile process with TDD integration points

Conclusion

"Based on the findings of the existing studies, it can be concluded that TDD seems to improve software quality, especially when employed in an industrial context. The findings were not so obvious in the semi industrial or academic context, but none of those studies reported on decreased quality either. The productivity effects of TDD were not very obvious, and the results vary regardless of the context of the study. However, there were indications that TDD does not necessarily decrease the developer productivity or extend the project lead times: In some cases, significant productivity improvements were achieved with TDD while only two out of thirteen studies reported on decreased productivity. However, in both of those studies the quality was improved."

 

References

• en.wikipedia.org/wiki/Test-driven_development

• searchsoftwarequality.techtarget.com/.../test-driven-development

• citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1

• www.acm.org/src/subpages/gf.../DavidJanzen_src_gf06.pdf

• https://www.ibm.com/developerworks/mydeveloperworks

• www.methodsandtools.com/archive/archive.php?id=20

• www.webopedia.com/TERM/T/test_driven_development.html