Using Cobertura

Introduction

EasyTest can be run under Cobertura (eCobertura, for Eclipse plugin) as you would do with JUnit. This is not a guide to Cobertura, but a help to error handling.

InvocationTargetException: Expected stackmap frame at this location

A new check bytecode validation introduced in Java 7 can throw an exception as follows:

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at org.easetech.easytest.runner.TestConfigUtil.loadTestBeanConfig(TestConfigUtil.java:52)
	at org.easetech.easytest.runner.RunnerUtil.loadBeanConfiguration(RunnerUtil.java:55)
	at org.easetech.easytest.runner.DataDrivenTestRunner.<init>(DataDrivenTestRunner.java:118)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
	at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
	at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.easetech.easytest.runner.TestConfigUtil.loadConfigBeans(TestConfigUtil.java:82)
	at org.easetech.easytest.runner.TestConfigUtil.loadTestBeanConfig(TestConfigUtil.java:46)
	... 20 more
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 140
Exception Details:
  Location:
    es/test/common/utils/ContextProvider.<clinit>()V @72: goto
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0000000: 033b 11ff ff3c 1218 1100 27b8 001e 1202
    0000010: b800 24b3 0026 1218 1100 2cb8 001e 01b3
    0000020: 0028 1218 1100 31b8 001e 01b3 002a 1218
    0000030: 1100 adb8 001e bb00 0259 b700 2db3 0028
    0000040: 1218 1100 afb8 001e a700 444d 1218 1100
    0000050: b0b8 001e 2cb3 002a 1218 1100 b2b8 001e
    0000060: bb00 2f59 b700 304e 1218 1100 b3b8 001e
    0000070: 2d2c b600 34b6 0038 1218 1100 b4b8 001e
    0000080: b200 262d b600 3bb9 0041 0200 1218 1100
    0000090: b6b8 001e b1                           
  Exception Handler Table:
    bci [46, 64] => handler: 75
  Stackmap Table:
    same_locals_1_stack_item_extended(@75,Object[#22])
    same_frame_extended(@148)

	at es.test.common.utils.TestConfigProvider.userContextAnonymous(TestConfigProvider.java:15)
	... 26 more

The important message is Expected stackmap frame at this location, and it's given to a strict validation of Java 7. For you interest, you can read [Verification of class Files] (http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10) on Oracle docs.

Dispite documentation indicates this validation is introduced since Java 6, at really its implemented to work since Java 7.

Fast solution is avoiding Java verification executing the JVM with the parameter -noverify. If possible, do not use the equivalent parameter -XX:-UseSplitVerifier, because is deprecated since Java 7 and it's not working in Java 8.

There are many rules to have in mind when validating the code to avoid using this parameter, so we are not discusing how to solve every situation.