-
Notifications
You must be signed in to change notification settings - Fork 894
fixes evaluation order of stack trace #8568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This version works for ant projects.
solves #8567 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. The approach makes sense to me. I left a few inline comments. For individual commits: They can be separate, but don't need to be. For the summary of the commit I would suggest:
"JUnit: Fix 'jump to test' for failing unittests"
If I understand it correctly, The stacktrace jumping itself is not affected, it is just the jump, when a failing testcase is selected and a non-stacktrace line is selected and thus no "real" target can be determined.
// if not found, return top line of stack trace. | ||
if (index == st.length) { | ||
index=0; | ||
while(true) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is broken. The loop will not end, you are not incrementing index
and even if, the target method might not be on the stack. So I suggest:
while(true) { | |
for(index=0; index < st.length; index++) { |
As long as index
is not modified outside the loop initilizer, this will not be an infite loop and still retain the early exist option.
// if that fails, return the test file object. | ||
if (file == null) { | ||
|
||
file = testfo; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have methodNode
availble, I suggest to fallback to openTestMethod
.
@@ -188,14 +188,18 @@ public void openCallstackFrame(Node node, @NonNull String frameInfo) { | |||
if (testfo != null && file == null && methodNode.getTestcase().getTrouble() != null && lineNumStorage[0] == -1) { | |||
//213935 we could not recognize the stack trace line and map it to known file | |||
//if it's a failure text, grab the testcase's own line from the stack. | |||
String fqMethodName= methodNode.getTestcase().getClassName()+ '.'+ methodNode.getTestcase().getName(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not work (at least in my tests it does not). The name of the testcase also holds the class name, but maybe that is already the problem and we should fix it at the root?!
This is the code I use to fix the nested test cases:
Seems for ant this is not a problem as the report is extracted differently.
String[] st = methodNode.getTestcase().getTrouble().getStackTrace(); | ||
if ((st != null) && (st.length > 0)) { | ||
int index = st.length - 1; | ||
int index = 0;//st.length - 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the old code. If it is needed, version history is there.
int index = 0;//st.length - 1; | ||
//213935 we need to find the testcase linenumber to jump to. | ||
// and ignore the infrastructure stack lines in the process | ||
while (!testfo.equals(file) && index != -1) { | ||
file = UIJavaUtils.getFile(st[index], lineNumStorage, locator); | ||
index = index - 1; | ||
while (!testfo.equals(file) && index < st.length) { | ||
if (st[index].contains(fqMethodName)) { | ||
file = UIJavaUtils.getFile(st[index], lineNumStorage, locator); | ||
break; | ||
} | ||
index++; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int index = 0;//st.length - 1; | |
//213935 we need to find the testcase linenumber to jump to. | |
// and ignore the infrastructure stack lines in the process | |
while (!testfo.equals(file) && index != -1) { | |
file = UIJavaUtils.getFile(st[index], lineNumStorage, locator); | |
index = index - 1; | |
while (!testfo.equals(file) && index < st.length) { | |
if (st[index].contains(fqMethodName)) { | |
file = UIJavaUtils.getFile(st[index], lineNumStorage, locator); | |
break; | |
} | |
index++; | |
// 213935 we need to find the testcase linenumber to jump to. | |
// and ignore the infrastructure stack lines in the process | |
for(int index = 0; !testfo.equals(file) && index < st.length; index++) { | |
if (st[index].contains(fqMethodName)) { | |
file = UIJavaUtils.getFile(st[index], lineNumStorage, locator); | |
break; | |
} | |
} |
This version works for ant projects. (Including netbeans projects).
This PR closes #8567
This implementation of finding file object+line number reverses the search by starting at the top of the stack and try to find the stack frame that is directly related to the test method.
It reverses the loop running from bottom to top into running from the top stack frame to the bottom one.
It effectively tries to find the first stack element that matches the testMethod involved instead of the first element that is NOT in some (testing) framework. For most tests this appears to be the logical choice, in particular in the non-optimal practice of having multiple assert or assert-like statements in one test method.
For NetBeans developers, in particular those working on refactoring related stuff and tests, it is more useful to point to the failing assert or verifyXXX call than in some method inside some method inside the test class or a superclass thereof that generalizes repetitive work in the tests.
In the original the goto source landed me in
netbeans/java/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/RefactoringTestBase.java
Lines 405 to 418 in 68e420d
instead of say line 118 below, which is the more logical line to choose in most cases.
netbeans/java/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/InnerToOutterTest.java
Lines 117 to 118 in 68e420d
This PR solves the problem for both maven and ant projects in a similar way.