Beiträge mit dem Tag ·

testing

·...

Testing the coverage metric of JMockIt

4 kommentare

After yesterdays article about Code Coverage terminology I thought more about the code coverage metric JMockIt uses. I created a simple class to get more insights:

CoverMeSimple.java

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;
    }
}

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. So I wrote this little unit test:

CoverMeSimpleTest.java

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);
    }
}

And here is the resulting JMockit coverage report:

JMockit Coverage Report of CoverMeSimple

JMockit Coverage Report of CoverMeSimple

JMockit detailed Coverage Report on CoverMeSimple

JMockit detailed Coverage Report on CoverMeSimple

As you can see, 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:

JMockit Coverage report for modified CoverMeSimple

JMockit Coverage report for modified CoverMeSimple


JMockit detailed Coverage report for modified CoverMeSimple

JMockit detailed Coverage report for modified CoverMeSimple

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.

*Update* I created a Cobertura coverage report for CoverMeSimple now:

CoverMeSimple Cobertura coverage report

CoverMeSimple Cobertura coverage report

Code Coverage – what are we talking about?

1 kommentar

Today an interesting discussion about the definition of code coverage took place in the JMockit Users group. I hope my english was good enough to follow the details and maybe contribute something useful. ;-)

There was a bit of a confusion about the kind of coverage analysis JMockIt does for its coverage reports. For me, as an ISTQB certified tester, the german terms Anweisungsüberdeckung, Zweigüberdeckung and Pfadüberdeckung have a clear meaning. It’s based on the ISTQB definitions. The german Wikipedia article Kontrollflussorientierte Testverfahren has a good explanation of all the different coverage analysis. (Including the Bedingungsüberdeckung, which you can have the most fun with. And with fun I mean sleepless nights of whitebox testing… ;-) )

Unfortunatly most of the tools doing some kind of code coverage analysis try to explain their metrics without the use of control flow graphs or any other kind of graphical representation. I think this adds to the confusion.

Using real world terms like branch and path don’t help to clear things up either. That 100% branch coverage means empty branches too isn’t very clear for the beginner who thinks of a branch as a real world thing.

After all this discussion shows once again, that you really have to know the metrics you use or chance is good you’re measuring the wrong things.