Tag Archives: Test Driven Development

Using Mockito with Spring

Junit testing is an integral part of unit testing while developing any application. It makes sense at times to separate out testing of Business layer from DAO layer to avoid generation of test data everytime or may be DAO layer is being developed independently.

Frameworks like Mockito or Easymock comes handy when dealing with such situations where you only want to test one class or one method and mock any other dependencies by dummy objects.

Here is a simple example


@RunWith(MockitoJUnitRunner.class)
public class UserManagerTest{
	private static final String userName="kamal";
	
	@InjectMocks
	private UserManager userManager=new UserManager();
	
	@Mock
	private UserDAO userDAO;
	

	@Before
	public void initMocks() {
		MockitoAnnotations.initMocks(this);
	}
	
	//Remove the Ignore tag to execute the test case
	@Ignore
	@Test
	public void addUserTest()
	{
		try {
		
			Mockito.doNothing().when(userDAO).insertUser(userName);
			Mockito.when(userDAO.getUserDependencies(userId)).thenReturn(new UserDependencies("temp"));
			
			userManager.addUser(userName);
		} catch (Exception e) {
			fail("Test case failed");
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
	

}

We are calling userManager.addUser(userName), but at the same time we are telling JUnit to do nothing (do not call the DAO layer), when you see this call to avoid data insertion. In addition there is another method which will check user dependencies (may be after adding user it check if there are some default depenedencies), where we tell Junit to instead of calling real DAO method and fecthing an objects, lets return a dummy object.

Test Driven Development

One of the most important practices of Agile development process is Test Driven Development (TDD). It is not a complex term to understand, TDD simply means you are aware of test cases before you actually start development of a piece of code. You are supposed to write test cases, automated test scripts, Junit test suite before you actually went on to write the real code.

Though the concept is simple, but in real world the implementation is not that easy. Why? Lets look at some of the key challenges.

Challenges for TDD

1. How can you create a test plan for something which does not even exist?
2. What if Requirement gets changed or modified? Instead of just making code change, we are making change to test plan as well. If we were creating tests after code completion, we will have saved ourselves from the trouble of making the changes to test plan.

Ok we have talked about the challenges, so why should we take so much pain and not just stick to the regular practice of writing test cases after writing the code.

Advantages of TDD

1. You can test the code implementation the moment you have written it without waiting for the test to be ready as the test was written before code.
2. Errors are caught at the early stage rather than propagating till late stages.
3. Test cases can be confirmed by business team, so that any discrepancy in the requirements can be figured out at an initial stage.
4. Most importantly, a TDD makes sure improvement in code quality. As the test cases are written in advance, it makes sure that all the code written passes the test before getting checked in.