In my previous posts I’ve covered some of the automated integration testing frameworks such as Arquillian and Selenium. I’ve explained how it is important to have a solid automated testing to do continues code refactor and evolving technology architecture based on dynamic business needs. In this post I’m going to share some of my view and understanding of Test Driven Development (TDD)
What is TDD ?
ever since Kent Beck introduced JUnit (Rated as one of the top 5 tool for Java Technology ever made), and he rediscovered the whole Test Driven Development progress. According to the Wikipedia definition, TDD is a development process which relies on the repetition of a very short development life cycle. The developer write the test case showing how the system fails and then refactor the code to make it success.
TDD Process :
Many misunderstood TDD is all about writing test cases. TDD is a process that differentiate software engineering from plain programming. It has the following itineraries.
1. Plan:
Read the requirement and business use case. plan what method you going to implement and how you going to implement it.
2. Write a test case to fail:
This is very important. Once you done the planning, don’t jump in to implementation. Write test cases for that function and show what way it can fail.
3. Implement the functionality:
Now you refactor the implementation code as per the requirement.
4. Write test cases to pass:
Now the method already fool-proof. we have covered all the scenario, how not to fail. Run the test cases and see it run successfully.
5. Repeat (1 – 4)
TDD basically enforce the very basic of the software programming, “Code for Failure”. If you are new to software programming, a typical method should look like
function x(int x) {
< pre condition> (what should we do if we get x value undesirable)
Your Business logic
<Post condition> (did you got the desired result)
}
Lets Take a simple example. We need to implement a simple divider function, that take two integers as input and produce the division as output. We have simple business validation.
1. The denominator should be zero
2. The result should not be in negative number. (which means neither of the variable should be in negative)
Lets do a TDD.
1. Plan:
As we have two business use case validation, we need to have a custom exception class.
Write a simple method that will take two integer parameter and do the division operation.
2. Write Test case to fail
Lets write the basic class now.
DataFlow.java (The exception class)
package org.ananth.learning.tdd;
/**
* The is the custom data exception
* @author Ananth
*
*/
public class DataException extends RuntimeException{
public DataException(String message) {
super(message);
}
}
</pre>
package org.ananth.learning.tdd;
/**
* Simple divider implementation
* @author Ananth
*
*/
public class SimpleDivider {
/**
* Take integer A,B and result the divider
* @param a
* @param b
* @return
*/
public Integer divide(Integer a, Integer b) {
return a/ b;
}
}
<pre>
Now the test cases to fail
package org.ananth.learning.tdd.test;
import static org.junit.Assert.*;
import org.ananth.learning.tdd.DataException;
import org.ananth.learning.tdd.SimpleDivider;
import org.junit.Test;
/**
* Test methods for simple divider
* @author Ananth
*
*/
public class SimpleDividerTest {
/**
* Denominator Zero
*/
@Test(expected = DataException.class)
public void testZeroDivisor() {
new SimpleDivider().divide(10, 0);
}
/**
* Negative denominator and positive Numerator
*/
@Test(expected = DataException.class)
public void testNegetiveDivisorA() {
new SimpleDivider().divide(10, -2);
}
/**
* Negative Numerator and positive denominator
*/
@Test(expected = DataException.class)
public void testNegetiveDivisorB() {
new SimpleDivider().divide(-10, 2);
}
/**
* Negative Numerator and denominator
*/
@Test(expected = DataException.class)
public void testNegetiveDivisorAB() {
new SimpleDivider().divide(-10, -2);
}
/**
* Actual Test to pass
*/
@Test
public void testDivisor() {
assertEquals(new Integer(5),new SimpleDivider().divide(10, 2));
}
}
Now if you run the test cases you can see except the last test case all the test cases been failed. Because we have not build out implementation method for failure.
Step 3: Refactor the code.
Now I’ve refactor the implementation method to include precondition to handle failures.
public Integer divide(Integer a, Integer b) {
if(b == 0) {
throw new DataException("Can't allow zero as divisor");
}
if(a < 0 || b < 0) {
throw new DataException("Values can't be in negative");
}
return a / b;
}
Now you can see all the precondition has been properly implemented and exceptions been thrown.
Step 4: See the test pass through
Now you can rerun the test cases and see everything pass through.
Step 5:
Take another modular method and repeat step 1-4.
Happy TDD!!!!
bigdatanerd 