Test it, forget it!
by admin | Jun 14, 2010
Test-Driven Development concentrates much on the test driven approach in both design and development. Test Driven Development (TDD) is a simple approach for development. It is a two way process:
(i) “test-first”, where we write a test code
(ii) “production code” to fulfill those tests and do the refactoring(if any).
To put it in simple terms, it’s a way to think through our design before we write our functional code. We will get into the details of TDD in the next few sections.
What exactly is TDD?
A simple representation of TDD is combining both “Refactoring Code” and “Test First Design”. Test Driven Development (TDD) can be looked at, in a step by step method.
The first step is to quickly add a test, usually just enough code to fail. Next we run our tests, often the complete test suite, to ensure that the new test does fail(mostly). We then update our functional development code, to make it pass new tests. Run the tests again. If they fail, update the functional code and re-test. Once all the tests pass, the next step is to start over(we may first need to re-factor any duplication out of the design as needed).
Two simple rules for TDD:
(i) Write new business code, only when the test code has failed.
(ii) Eliminate duplication, if any.
Example:(Junit)
Here is a small example to add two numbers. Initially there will be no functional code(Iteration 0).
-> First step is to write the test code, run it; which will fail as there is no functional code.
-> The first functional code(Iteration 1) will be written, and then run test code.
-> Then we write our business code(Iteration 1) and try to fulfill the test code. Run the test code again. This will not give us the expected results we re-factor the code(Iteration 2) and then again run the test. This process will be repeated until our tests passes. Here in this case, it will pass after Iteration 2.
Test code
public void testAdd(){
int sum= add(10,20);
assertTrue(sum==30);
}
Business code
Iteration 0:
public int add(int a1,int a2){
// No code
}
Iteration 1:
public int add(int a1,int a2){
return -1;
}
Iteration 2:(Refactor after test failure)
public int add(int a1,int a2){
return (a1+a2);
}
Benefits of Test-Driven Development
o-> A significant advantage of TDD is that it enables you to take small steps when writing code.
o-> Running the suites of unit test always gives the feedback – if each module is still in working condition. The unit tests act as documentation that does not go out-of-date, unlike separate documentation.
o-> If the unit test passes and the production code is modified to remove duplication, it is clear that the code is final, and we can move on to a new test.
o-> Test-driven development enforces critical analysis and design, as the developer cannot write the production code without truly understanding the desired results and how exactly to test it.
o-> The software tends to be better designed – loosely coupled and easily maintainable, because the developer is free to make design decisions and re-factor at any time, with the confidence that the software is still working. This confidence is gained by running the tests at each stage.
o-> Regression safety net on bugs. If a bug is found, the developer should create a test to reveal the bug and then modify the production code, so that the bug is fixed, and all other tests still pass. On each successive test run, all previous bug fixes are verified.
o-> Reduced bugging time! – read it as reduced debugging time.
TDD Vs Traditional Testing
TDD is primarily a design technique, with a side effect of ensuring thoroughly unit tested source code. With traditional testing, a successful test finds one or more bugs. With TDD, you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t always give.
TDD increases developer confidence, by ensuring that the system actually meets the requirements defined for it, and that the system actually works!
TDD and Documentation
Do your tests have sufficient documentation? Very likely not, but they do form an important part of it. Like it or not, most developers don’t read the documentation for a system, instead they prefer working with the code. And there’s nothing wrong with this. When trying to understand a class or operation, most programmers will first look for sample code that already invokes it.
Well-written unit tests do exactly this – they provide a working specification of our functional code – and as a result, unit tests become a significant portion of the technical documentation.
Tools
Some of TDD tools available for us are:
About the author:
Girish Kodupurath, a Senior Software Engineer at Bobcares, working since January 2007. He is a SCJP certified Java developer and also has experience in developing web based PHP applications. His major achievement lies in the contribution to the open source project VTONF. He is passionate in writing parsing scripts and JAVA programs.
Co-Authored by Sankar.H
0 Comments