Inadvertently , we might have done this in past for one or more of our projects. I have done something similar in one of my projects without following the regression testing rule exhaustively.
The way it works - several iterations of the following steps:
- Write a test case for a small feature: use the requirement and the use cases to write test cases.
- Make sure that the test case fails (you haven't written the code for this feature) : There might be a "bug" in your program which gives you this "feature". This requirement basically means "start with a clean slate".
- Write the code necessary to pass the current test case.
- Refractor code - making sure that the code for the new feature fits in the design or the other parts of the code are adjusted to make it the simplest design.
- Regressing testing - run all the test cases written so far
Advantages
- Due to regression testing requirement , the modules are written in a modular way which can be tested individually and hence aids object oriented design.
- Takes out a huge amount of time from a manual regression testing process
- Coding is always done an incremental fashion which makes a loosely coupled system
- Testing for each feature is NOT done as an afterthought
- The initial test case document provides a good document for system capabilities
Limitations and challenges :
- A sound automated testing environment is required to ensure regression testing - hence additional effort required initially. (JUnit is an example of automated testing infrastructure for java and boost test for c++).
- Distributed objects in an environment - can write "mock" objects to support this
- A test driven environment is as good as the test cases, since they are the key design driver.
References :
http://www.objectmentor.com/writeUps/TestDrivenDevelopment
http://en.wikipedia.org/wiki/Test_driven_development
No comments:
Post a Comment