TestNG : Expected Exception Test

It is always good to test the working and output of your unit. But it is more important to test the negative behavior to make application robust. What if you are expecting an exception from a part of code which is not thrown. the point where application has to get terminated, it is moving smoothly to get a dead lock or a pitty crash. Just to save such situation Testing of exception generation is code is very important. There are annotation in TestNG frame work which helps to make is an easy task.

Example

import org.testng.annotations.*;

public class TestNGTest2 {

	@Test(expectedExceptions = ArithmeticException.class)  
	public void divisionWithException() {  
	  int i = 1/0;
	}  

}

In above example, the divisionWithException() method will throw an ArithmeticException Exception, since this is an expected exception, so the unit test will pass.

More advanced example can be observed in the snap shot attached.
Where the scenarios to test says – “Calling this method with null argument throws Exception”.
The test will go green if exception is thrown, else it will go red.

Testing the expected exception

Importance of flushing data in unit test cases

While writing unit tests it is a good practice to clear and flush the session. When application is executed in real time there are several request and response or different transactions due to which the session/cache gets cleared. However while running unit test, everything happens as the part of single process ie the session (especially hibernate) has rotten values or old references which gives some exceptions at times.

Exception :
org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.ptc.fusion.model.learningitem.OnlineCourse#1]
at org.hibernate.engine.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:613)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate

Code Example :

learningItemRepository.saveLearningItem(c3);

sessionFactory.getCurrentSession().flush();
sessionFactory.getCurrentSession().clear();

Map<FusionLocale, RootLearningItem> mapBeforeUnMapping = learningItemService.findEquivalentLearningItems(c2);
assert mapBeforeUnMapping.size() == 2;
assert mapBeforeUnMapping.values().contains(c1);
assert mapBeforeUnMapping.values().contains(c2);

sessionFactory.getCurrentSession().flush();
sessionFactory.getCurrentSession().clear();

boolean unMappingSuccessful = learningItemService.unMapEquivalentLearningItem(c1);
assert  unMappingSuccessful;

Hence it is always a good practice to clear/flush session after repository calls or hibernate transactions to make unit test case robust.