[jbossts-issues] [JBoss JIRA] Commented: (JBTM-727) Emma coverage missing some method invocations
Andrew Dinn (JIRA)
jira-events at lists.jboss.org
Thu Mar 11 12:27:37 EST 2010
[ https://jira.jboss.org/jira/browse/JBTM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12519502#action_12519502 ]
Andrew Dinn commented on JBTM-727:
Hmm, interesting! The coverage result is maybe half right and half wrong.
Here is the source and the corresponding instrumented bytecode for the ServerOSITopLevelAction.commit()
public void commit () throws SystemException, NotPrepared, HeuristicRollback, HeuristicMixed, HeuristicHazard
com.arjuna.ats.jts.logging.FacilityCode.FAC_OTS, "ServerOSITopLevelAction::commit for "+_theUid);
public void commit() throws org.omg.CORBA.SystemException, org.omg.CosTransactions.NotPrepared, org.omg.CosTransactions.HeuristicRollback, org.omg.CosTransactions.HeuristicMixed, org.omg.CosTransactions.HeuristicHazard;
0: getstatic #129; //Field $VRc:[[Z
4: ifnonnull 11
8: invokestatic #139; //Method $VRi:()[[Z
14: getstatic #2; //Field com/arjuna/ats/jts/logging/jtsLogger.logger:Lcom/arjuna/common/util/logging/LogNoi18n;
17: invokeinterface #3, 1; //InterfaceMethod com/arjuna/common/util/logging/LogNoi18n.isDebugEnabled:()Z
26: ifeq 72
29: getstatic #2; //Field com/arjuna/ats/jts/logging/jtsLogger.logger:Lcom/arjuna/common/util/logging/LogNoi18n;
32: ldc2_w #16; //long 16l
35: ldc2_w #4; //long 4l
38: ldc2_w #6; //long 256l
41: new #8; //class java/lang/StringBuilder
45: invokespecial #9; //Method java/lang/StringBuilder."<init>":()V
48: ldc #26; //String ServerOSITopLevelAction::commit for
50: invokevirtual #11; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
54: getfield #19; //Field _theUid:Lcom/arjuna/ats/arjuna/common/Uid;
57: invokevirtual #20; //Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
60: invokevirtual #14; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
63: invokeinterface #15, 8; //InterfaceMethod com/arjuna/common/util/logging/LogNoi18n.debug:(JJJLjava/lang/String;)V
73: invokevirtual #21; //Method get_uid:()Lcom/arjuna/ats/arjuna/common/Uid;
76: invokestatic #22; //Method com/arjuna/ats/internal/jts/interposition/resources/osi/OTIDMap.remove:(Lcom/arjuna/ats/arjuna/common/Uid;)Z
81: invokespecial #27; //Method com/arjuna/ats/internal/jts/orbspecific/interposition/resources/strict/ServerStrictTopLevelAction.commit:()V
Ok, I know that's a lot of wtf but the important bit is those sequences in the form
They set flags in a boolean which indicate that a specific path segment through the code has been traversed. In this case emma sees 3 segments:
method entry to if (debugEnabled)
inside if (debugEnabled)
endif (debugEnabled) to return
Each segment is tailed by one of those array flag writes which records that the preceding segment has actually been traversed.
Each segment is supposed to be a basic block i.e. it contains no control-flow. However, emma has a flawed concept of 'basic block' because the last segment contains impllicit control flow due to the fact that super.commit() can throw an exception. (This test -- and, it appears, all other tests -- does in fact throw an exception in commit() so the results indicate that OTIDMap.remove() and super.commit() have not been successfully called. By contrast, it appears that there are cases where rollback does not throw an exception which explains why it gets more full coverage.)
Strictly, the last segment in commit should be split in two before the call to super.commit. If this were done then the test would then show that the call to OTIDMap.remove() was made and returned normally but that the call to super.commit() was made but did not complete.
I say that emma is _maybe_ half right but that's also questionable. The call to commit was made but did not complete. So, the line for commit probably should be shown as covered and the last line of the method (where the implicit return happens) should be shown as not covered. In order to do this emma probably needs to inject the code which set flags at the _start_ of basic blocks. That would have to include a new basic block which includes the implicit return following super.commit().
So, two things to patch in emma to fix this one. I'll stick them on the list of things to patch and also post a defect for the emma maintainer.
> Emma coverage missing some method invocations
> Key: JBTM-727
> URL: https://jira.jboss.org/jira/browse/JBTM-727
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Reporter: Mark Little
> Assignee: Andrew Dinn
> Fix For: 4.11.0
> There are some class that emma says don't have coverage and yet there are tests that do cover them (and I have confirmed the methods get called). For instance ServerTopLevelOSIActionUnitTest which covers ServerOSITopLevelAction. The commit and rollback methods are invoked, yet emma misses them.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues