Testing the coverage metric of JMockIt
Von Carsten
After yesterdays article about Code Coverage terminology I thought more about the code coverage metric JMockIt uses. I created a simple class and a unit test to get more insights:
CoverMeSimple
package de.kopis.katas;
public class CoverMeSimple {
public int simple(int x, int y) {
int z = x;
if(y > x)
z = y;
z *= 2;
return z;
}
}
CoverMeSimpleTest
package de.kopis.katas;
import static org.junit.Assert.assertEquals;
import mockit.integration.junit4.JMockit;
import org.junit.Test;
import org.junit.runner.RunWith;
@RunWith(JMockit.class)
public class CoverMeSimpleTest {
@Test
public void testSimple() {
CoverMeSimple cm = new CoverMeSimple();
int result = cm.simple(1, 2);
assertEquals(4, result);
}
}
This is as simple as it gets. The example is taken from the Wikipedia page on Kontrollflussorientierte Testverfahren again. For 100% statement coverage you only need one test case, in which y > x
. Then all statements are executed and you have 100% statement coverage.
JMockit tells us that every single statement is executed, exactly 1 time, with this test case. And that’s exactly what I understand as statement coverage and it is in full compliance to the ISTQB terminology. Now, to make my point really clear, let me change the class as follows:
package de.kopis.katas;
public class CoverMeSimple {
public int simple(int x, int y) {
int z = x;
if(y > x) {
z = y;
} else {
}
z *= 2;
return z;
}
}
I added the empty ELSE statement that I omitted first. And I run JMockit again to get a new coverage report. This is not 100% branch coverage, ISTQB certified or not. 😉 My point on this is, if you want to use a tool to verify your testing requirements, make sure that you know what the tool is measuring. And make sure you read the discussion thread in the JMockit users group.