Testing the coverage metric of JMockIt

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.