I was looking through some codes and found multiple assert methods in a single test.

Problem Area

@Test
public void testGetMapping() {
	try {
		PpxxMap bo = xxService.getxxId(102);
		assertEquals("1234567", bo.getBankAccNum());
		assertEquals("111", bo.getBranch().getBranchCode());
		assertEquals("7678", bo.getBranch().getBank().getBankCode());
	} catch (AppBizException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
}

While this works fine (compilable), it is a clear violation of the Unit Testing best practice: One domain assert per test. More elaboration on this once i get to my sources (JUnit in Action Second Edition by Manning) … and why that. (Update in a few hours)

Fix

@Test
public void test_getMapping_validBackAccNum(){
	try{
		Ppxxmap bo = xxService.getxxId(102);

		assertEquals("1234567", bo.getBankAccNum());
	} catch (AppBizException e) {
		e.printStackTrace();
	}
}

@Test
public void test_getMapping_validBranchCode(){
	try{
		Ppxxmap bo = xxService.getxxId(102);

		assertEquals("111", bo.getBranch().getBranchCode());
	} catch (AppBizException e) {
		e.printStackTrace();
	}
}

@Test
public void test_getMapping_validBankCode(){
	try{
		Ppxxmap bo = xxService.getxxId(102);

		assertEquals("7678", bo.getBranch().getBank().getBankCode());
	} catch (AppBizException e) {
		e.printStackTrace();
	}
}


The tests when broken down into singularity by having one assert statement to one test case, we manage to provide a clearer picture to the tester (especially if the test case fails), which of the three assert statements fired failed. Rather than depending on the trace stack.


JUnit Method Naming Convention

The JUnit method naming convention goes like testXXXX(): void, where XXXX is your business method, thus with a typical method signature looking like:

public testWithdrawCash(){
	...
}

public testGetSumOfTwo(){
	...
}

However, this convention goes only as far as useful when there is only one test per business method. What if we have the above scenario whereby we need multiple test per business method – JUnit states that we append the “purpose” at the back of the method.

public testWithdrawCashCheckPayment(){
	...
}

public testWithdrawCashCheckPayee(){
	...
}

public testGetSumOfTwoCheckNull(){
	...
}

public testGetSumOfTwoCheckInteger(){
	...
}

With that, the method names (although legal, correct, and adheres to the JUnit best practice) is not so readable. Therefore, we may make our test codes more readable by introducing the underscore ( _ ) symbol which separates the business method name from the test purpose we need to append at the back.

public test_WithdrawCash_CheckPayment(){
	...
}

public test_WithdrawCash_CheckPayee(){
	...
}

public test_GetSumOfTwo_CheckNull(){
	...
}

public test_GetSumOfTwo_CheckInteger(){
	...
}

or

public testWithdrawCash_CheckPayment(){
	...
}

public testWithdrawCash_CheckPayee(){
	...
}

public testGetSumOfTwo_CheckNull(){
	...
}

public testGetSumOfTwo_CheckInteger(){
	...
}


Reference

[1] JUnit Recommended Best Practices [Online]

Available at http://www.codign.com/pdf/junitbprac.pdf [Accessed January 12, 1010]


[2] JUnit best practices [Online]

Available at http://www.digitalprank.org/junit-best-practices/ [Accessed January 12, 2010]

Share