[
https://issues.apache.org/jira/browse/NETBEANS-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ratcash Developer updated NETBEANS-4842:
----------------------------------------
Description:
JUnit4 and TestNG logs tested method names like:
{noformat}
testResults.MainTest > testA
{noformat}
However, JUnit5 adds the method's parameters, like this:
{noformat}
testResults.SecondaryTest > testA()
testResults.SecondaryTest > testB()
testResults.SecondaryTest > [1] 1, 2
{noformat}
The last one is a result of using
{noformat}
@ParametrizedTest
@MethodSource("generate")
public void testC(String a, String b) {
// do something clever
}
{noformat}
Such method names are not understood by the "Go To Source" functionality.
For gradle projects a very-dirty work-around may be the following change to
clean method names:
{code:java}
---
a/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
+++
b/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
@@ -260,8 +260,10 @@ public final class GradleTestProgressListener implements
ProgressListener, Gradl
}
- private String searchLocation(String className, String methodName,
String[] stackTrace) {
- StringBuilder ret = new StringBuilder(className.length() +
methodName.length() + 10);
+ private String searchLocation(String className, String rawMethodName,
String[] stackTrace) {
+ StringBuilder ret = new StringBuilder(className.length() +
rawMethodName.length() + 10);
+ // cleanup necessary for JUnit5 method names
+ String methodName = rawMethodName.replaceAll("\\(.*", "");
String fileName = null;
String line = null;
if (stackTrace != null) {
{code}
Certainly, it'd much better if the "Jump to source" locator would become able
to interpret method names with parameters and thus able navigate between
overloaded methods.
was:
JUnit4 and TestNG logs tested method names like:
{noformat}
testResults.MainTest > testA
{noformat}
However, JUnit5 adds the method's parameters, like this:
{noformat}
testResults.SecondaryTest > testA() STANDARD_OUT
Doing something 2.
testResults.SecondaryTest > testB() STANDARD_OUT
Doing something 2 different.
testResults.SecondaryTest > [1] 1, 2 STANDARD_OUT
Doing something 2 different.
{noformat}
The last one is a result of using
{noformat}
@ParametrizedTest{noformat}
Such method names are not understood by the "Go To Source" functionality.
For gradle projects a very-dirty work-around may be the following change to
clean method names:
{code:java}
---
a/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
+++
b/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
@@ -260,8 +260,10 @@ public final class GradleTestProgressListener implements
ProgressListener, Gradl
}
- private String searchLocation(String className, String methodName,
String[] stackTrace) {
- StringBuilder ret = new StringBuilder(className.length() +
methodName.length() + 10);
+ private String searchLocation(String className, String rawMethodName,
String[] stackTrace) {
+ StringBuilder ret = new StringBuilder(className.length() +
rawMethodName.length() + 10);
+ // cleanup necessary for JUnit5 method names
+ String methodName = rawMethodName.replaceAll("\\(.*", "");
String fileName = null;
String line = null;
if (stackTrace != null) {
{code}
Certainly, it'd much better if the "Jump to source" locator would become able
to interpret method names with parameters and thus able navigate between
overloaded methods.
> Go To Source broken with JUnit5 (and Gradle)
> --------------------------------------------
>
> Key: NETBEANS-4842
> URL: https://issues.apache.org/jira/browse/NETBEANS-4842
> Project: NetBeans
> Issue Type: Bug
> Components: java - JUnit
> Reporter: Ratcash Developer
> Priority: Major
>
> JUnit4 and TestNG logs tested method names like:
> {noformat}
> testResults.MainTest > testA
> {noformat}
> However, JUnit5 adds the method's parameters, like this:
> {noformat}
> testResults.SecondaryTest > testA()
> testResults.SecondaryTest > testB()
> testResults.SecondaryTest > [1] 1, 2
> {noformat}
> The last one is a result of using
> {noformat}
> @ParametrizedTest
> @MethodSource("generate")
> public void testC(String a, String b) {
> // do something clever
> }
> {noformat}
> Such method names are not understood by the "Go To Source" functionality.
> For gradle projects a very-dirty work-around may be the following change to
> clean method names:
> {code:java}
> ---
> a/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
> +++
> b/java/gradle.test/src/org/netbeans/modules/gradle/test/GradleTestProgressListener.java
> @@ -260,8 +260,10 @@ public final class GradleTestProgressListener implements
> ProgressListener, Gradl
>
> }
>
> - private String searchLocation(String className, String methodName,
> String[] stackTrace) {
> - StringBuilder ret = new StringBuilder(className.length() +
> methodName.length() + 10);
> + private String searchLocation(String className, String rawMethodName,
> String[] stackTrace) {
> + StringBuilder ret = new StringBuilder(className.length() +
> rawMethodName.length() + 10);
> + // cleanup necessary for JUnit5 method names
> + String methodName = rawMethodName.replaceAll("\\(.*", "");
> String fileName = null;
> String line = null;
> if (stackTrace != null) {
> {code}
> Certainly, it'd much better if the "Jump to source" locator would become able
> to interpret method names with parameters and thus able navigate between
> overloaded methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
