In Java/Junit, I need to test for null with some object. There are a variety of ways I can test a condition but I have been using assertTrue for most of my tests. When I c
For most Boolean expressions, the Java compiler generates extra branches in the byte code. JaCoCo produces "branch coverage" based on the generated byte code, not based on the original Java code, and hence shows additional branch coverage information for almost any Boolean expression you would use.
In your code, the Boolean expression you use is myObject == null
.
To compute this value, the Java compiler generates code pushing the two arguments on the stack, and then doing a conditional jump in order to push 1 (true) or 0 (false) on the stack. JaCoCo reports the branch coverage of this conditional jump.
Thus, the fact that you use myObject == null
triggers the behavior you describe.
As some other examples, try this:
boolean t = true;
boolean f = false;
boolean result1 = (t && f) || f; // 3 out of 6 missed.
boolean result2 = !t; // 1 out of 2 missed.
This can be useful if the Boolean expression is, for example, returned by a function, which is used as condition in an if-then-else statement somewhere else. While mostly a consequence of the way the Java compiler works, it helps to assess condition coverage (instead of mere branch coverage) of the original Java code.
This feature isn't too well documented, but here are some pointers:
So it is, indeed, related to the extra byte code is generated, but not to the specific examples of synthetic byte compiler constructs for which the filtering options are intended.
NOTE: Did major EDIT since initial answer was too much of a guess. Thanks to @ira-baxter for good & critical discussion.
To get 100% code coverage on boolean methods, do the following
Class RecordService{
public boolean doesRecordExist(String id){
return id!=null;
}
}
//Method inside your mock
@Test
public boolean testDoesRecordExist(){
RecordService recordService = mock(RecordService.class);
when(recordService.doesRecordExists()).thenReturn(
anyString()).thenReturn(null);
}
The fact that Emma treats a conditional expression as "something with a branch" for (branch) coverage counting IMHO seems simply broken. It isn't a conditional branch.
We can argue more about the Assert; if it were defined as "throws exception on assert failure" then it really does have a conditonal branch; if it is defined [as I think i does, I'm not a Java expert] as "terminate my program on assert failure" then it isn't really a branch. Also obscure are method calls; these are conditional branches in the sense that if the called method throws an exception, control flow does not continue to the "rest of the statement".
Our Java Test Coverage tool gets the (branch) coverage analysis on such conditionals "right".