fixes evaluation order of stack trace

[homberghp]

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

	@Override
	protected void runTest() throws Throwable {
	//the tests are unfortunatelly not 100% stable, try to recover by retrying:
	Throwable exc = null;
	for (int i = 0; i < RETRIES; i++) {
	try {
	super.runTest();
	return;
	} catch (Throwable t) {
	if (exc == null) exc = t;
	}
	}
	throw exc;
	}

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

	performInnerToOuterTest(null);
	verifyContent(src,

This PR solves the problem for both maven and ant projects in a similar way.

[homberghp]

solves #8567

[matthiasblaesing]

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.

[matthiasblaesing]

You have methodNode availble, I suggest to fallback to openTestMethod.

[matthiasblaesing]

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:

https://github.com/apache/netbeans/pull/8664/files#diff-20f21830cc72d9977dabeae930571d61083d0f61de40c3fd9637e5c9c69ec461R223-R239

Seems for ant this is not a problem as the report is extracted differently.

[matthiasblaesing]

Please remove the old code. If it is needed, version history is there.

[matthiasblaesing]

@homberghp This currently fails to build from source. This import looks broken: jdk.internal.net.http.common.Log. Please fix, squash all changes and rebase onto current master.