Parameterized runner should name tests better than sequential numbers #44

Closed
anshnd opened this Issue Nov 16, 2009 · 42 comments

Comments

Projects
None yet
@anshnd

anshnd commented Nov 16, 2009

Right now the test names are named sequentially 0,1, etc in Parameterized:

@override
protected String getName() {
return String.format("[%s]", fParameterSetNumber);
}

@override
protected String testName(final Method method) {
return String.format("%s[%s]", method.getName(), fParameterSetNumber);
}

It would help if the data themselves were to be used in determining the name. Proposed alternatives for name (which has to be determinited statically before Test is instantiated):

  • call toString on first parameter
  • call the a newly added names attribute to Parameters annotation (with default empty names for compatibility)
    public String[] names() default {};
  • call a public, static (!) method annotated by newly-defined @testname
    and accepting the same arguments as the constructor

I can provide (again) a patch. This issue was tracked as http://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 and https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1630834&group_id=15278
I can submit a patch if needed

@JThoennes

This comment has been minimized.

Show comment Hide comment
@JThoennes

JThoennes Dec 8, 2009

How about this issue? The suggestions are good, when will you implement it / incorporate the patch?

Thanks, Jörg

How about this issue? The suggestions are good, when will you implement it / incorporate the patch?

Thanks, Jörg

@JThoennes

This comment has been minimized.

Show comment Hide comment
@JThoennes

JThoennes Dec 8, 2009

See also issue 24 which talks about the same topic, but was entered by dsaff.

See also issue 24 which talks about the same topic, but was entered by dsaff.

@jjunit2010

This comment has been minimized.

Show comment Hide comment
@jjunit2010

jjunit2010 Jan 24, 2010

Any more news on when this fix might be implemented?

Any more news on when this fix might be implemented?

@reccles

This comment has been minimized.

Show comment Hide comment
@reccles

reccles Feb 5, 2010

There appears to be some demand for this simple feature outside as well: http://stackoverflow.com/questions/650894/change-test-name-of-parameterized-tests

reccles commented Feb 5, 2010

There appears to be some demand for this simple feature outside as well: http://stackoverflow.com/questions/650894/change-test-name-of-parameterized-tests

@Yishai

This comment has been minimized.

Show comment Hide comment
@Yishai

Yishai Feb 5, 2010

As an additional (simpler) suggestion, how about just changing
@override protected String testName(final FrameworkMethod method) {
return String.format("%s%s", method.getName(),
Arrays.toString(fParameterList.get(fParameterSetNumber)));
}

Yishai commented Feb 5, 2010

As an additional (simpler) suggestion, how about just changing
@override protected String testName(final FrameworkMethod method) {
return String.format("%s%s", method.getName(),
Arrays.toString(fParameterList.get(fParameterSetNumber)));
}

@dbt

This comment has been minimized.

Show comment Hide comment
@dbt

dbt Feb 19, 2010

From my deployment experience (I forked Parameterized internally to my project and extended it with similar functionality), using toString or non-static testName() functions were suboptimal, and using a fixed portion of the parameters list (either the first parameter or all of them) was also not useful. My preferred solution was to support an annotated static method that took the same arguments as the constructor and returned a string, and fall back to the test number if that didn't work.

I'm happy to get the (fairly trivial) patch open sourced if that would help solve this problem.

Thanks,
-dave

dbt commented Feb 19, 2010

From my deployment experience (I forked Parameterized internally to my project and extended it with similar functionality), using toString or non-static testName() functions were suboptimal, and using a fixed portion of the parameters list (either the first parameter or all of them) was also not useful. My preferred solution was to support an annotated static method that took the same arguments as the constructor and returned a string, and fall back to the test number if that didn't work.

I'm happy to get the (fairly trivial) patch open sourced if that would help solve this problem.

Thanks,
-dave

@ralfebert

This comment has been minimized.

Show comment Hide comment
@JThoennes

This comment has been minimized.

Show comment Hide comment
@JThoennes

JThoennes Sep 28, 2010

Could this patch merged into the next JUnit release, please?

And when will the next release happen?

Could this patch merged into the next JUnit release, please?

And when will the next release happen?

@davidkarlsen

This comment has been minimized.

Show comment Hide comment
@davidkarlsen

davidkarlsen Oct 13, 2010

+1

+1

@kaipe

This comment has been minimized.

Show comment Hide comment
@kaipe

kaipe Jan 16, 2011

I have released a framework that offers a solution to this problem:
http://callbackparams.org The test-class runner that will probably solve most cases where this problem arises is ...
http://callbackparams.org/project/api-javadoc/org/callbackparams/junit4/EnumRunner.html ... and for more complex cases the rest of the framework has a lot to offer.

The key feature in regard to this issue is that tests are named by the overridden method java.lang.Object#toString(), which for enum-constants happen to return the name of the constant. If the enum-constant name won't do it is of course still possible to override java.lang.Object#toString() explicitly for those constants that need more verbose test-names.

Anyhow, I think that a solution that does not rely on the toString()-method is simply not very elegant.

kaipe commented Jan 16, 2011

I have released a framework that offers a solution to this problem:
http://callbackparams.org The test-class runner that will probably solve most cases where this problem arises is ...
http://callbackparams.org/project/api-javadoc/org/callbackparams/junit4/EnumRunner.html ... and for more complex cases the rest of the framework has a lot to offer.

The key feature in regard to this issue is that tests are named by the overridden method java.lang.Object#toString(), which for enum-constants happen to return the name of the constant. If the enum-constant name won't do it is of course still possible to override java.lang.Object#toString() explicitly for those constants that need more verbose test-names.

Anyhow, I think that a solution that does not rely on the toString()-method is simply not very elegant.

@mmakowski

This comment has been minimized.

Show comment Hide comment
@mmakowski

mmakowski Jul 8, 2011

+1

+1

@soehalim

This comment has been minimized.

Show comment Hide comment
@soehalim

soehalim Sep 7, 2011

+1

soehalim commented Sep 7, 2011

+1

@elygre

This comment has been minimized.

Show comment Hide comment
@elygre

elygre Sep 20, 2011

+1

elygre commented Sep 20, 2011

+1

@binkley

This comment has been minimized.

Show comment Hide comment
@binkley

binkley Oct 12, 2011

+1

binkley commented Oct 12, 2011

+1

@davidkarlsen

This comment has been minimized.

Show comment Hide comment
@davidkarlsen

davidkarlsen Oct 13, 2011

Cmon! Why can't you apply this Kent? You even have ready patches and the issue is ancient. Isn't good naming part of cleancode and TDD practices - or do we simply have to dump junit for testng?

Cmon! Why can't you apply this Kent? You even have ready patches and the issue is ancient. Isn't good naming part of cleancode and TDD practices - or do we simply have to dump junit for testng?

@sivaram-psg

This comment has been minimized.

Show comment Hide comment
@sivaram-psg

sivaram-psg Oct 13, 2011

+1

+1

@joelmheim

This comment has been minimized.

Show comment Hide comment
@joelmheim

joelmheim Oct 20, 2011

+1

+1

@stefanbirkner

This comment has been minimized.

Show comment Hide comment
@stefanbirkner

stefanbirkner Oct 20, 2011

Contributor

I like Dave's idea of a label method. It may look like

@Label
public String labelForParameters(Object... parameters) {
  ...
}

Hopefully there's time today or tomorrow evening to implement this.

Contributor

stefanbirkner commented Oct 20, 2011

I like Dave's idea of a label method. It may look like

@Label
public String labelForParameters(Object... parameters) {
  ...
}

Hopefully there's time today or tomorrow evening to implement this.

@jonfreedman

This comment has been minimized.

Show comment Hide comment
@jonfreedman

jonfreedman Oct 22, 2011

+1

+1

@stefanbirkner

This comment has been minimized.

Show comment Hide comment
@stefanbirkner

stefanbirkner Oct 24, 2011

Contributor

I'm just waiting for pull request #348

Contributor

stefanbirkner commented Oct 24, 2011

I'm just waiting for pull request #348

@bsbodden

This comment has been minimized.

Show comment Hide comment
@bsbodden

bsbodden Dec 14, 2011

+1

+1

@RaviH

This comment has been minimized.

Show comment Hide comment
@RaviH

RaviH Dec 20, 2011

+1 (guessing that's the way to vote it up?)

RaviH commented Dec 20, 2011

+1 (guessing that's the way to vote it up?)

@Tibor17

This comment has been minimized.

Show comment Hide comment
@Tibor17

Tibor17 Dec 21, 2011

Contributor

+1

Contributor

Tibor17 commented Dec 21, 2011

+1

@Jeanguitoune

This comment has been minimized.

Show comment Hide comment
@Jeanguitoune

Jeanguitoune Jan 3, 2012

+1

+1

@yurodivuie

This comment has been minimized.

Show comment Hide comment
@yurodivuie

yurodivuie Jan 17, 2012

+1. We've started keeping our own version of Parameterized to fix this problem, but it would be great to have this supported from the source.

+1. We've started keeping our own version of Parameterized to fix this problem, but it would be great to have this supported from the source.

@slongoni

This comment has been minimized.

Show comment Hide comment
@slongoni

slongoni Jan 25, 2012

+1

+1

@sharfah

This comment has been minimized.

Show comment Hide comment
@sharfah

sharfah Jan 26, 2012

+1

sharfah commented Jan 26, 2012

+1

@cwhite102

This comment has been minimized.

Show comment Hide comment
@cwhite102

cwhite102 Feb 7, 2012

+1

+1

@veger

This comment has been minimized.

Show comment Hide comment
@veger

veger Feb 20, 2012

+1

veger commented Feb 20, 2012

+1

@java-artisan

This comment has been minimized.

Show comment Hide comment
@java-artisan

java-artisan Feb 21, 2012

+1

+1

@lbuchy

This comment has been minimized.

Show comment Hide comment
@lbuchy

lbuchy Feb 22, 2012

+1

lbuchy commented Feb 22, 2012

+1

@mrmanc

This comment has been minimized.

Show comment Hide comment
@mrmanc

mrmanc Feb 29, 2012

+1

mrmanc commented Feb 29, 2012

+1

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Mar 1, 2012

+1

ghost commented Mar 1, 2012

+1

@mariusx

This comment has been minimized.

Show comment Hide comment
@mariusx

mariusx Mar 2, 2012

+1

mariusx commented Mar 2, 2012

+1

stefanbirkner added a commit to stefanbirkner/junit that referenced this issue Mar 2, 2012

Add names for parameterized tests. Fixes #24 and #44.
In order that you can easily identify individual test, you may provide
a name for the Parameters annotation.
 @Parameters(name="my test")
This name is allowed to contain placeholders, which are replaced at
runtime. The placeholders are
* {index} - the current parameter index
* {0} - the first parameter
* {1} - the second parameter
* ... - the other parameters
If you don't use the name parameter, then the current parameter index
is used as name.

Example:
When you use @Parameters(name="fib({0})={1}") with the Fibonacci
example, then you get test names like "fib(3)=2".

This feature is based on the work of Dimitar Dimitrov (pull request
#145).
Thank
you.
@jpfielding

This comment has been minimized.

Show comment Hide comment
@jpfielding

jpfielding Mar 12, 2012

+2

+2

@z3jiang

This comment has been minimized.

Show comment Hide comment
@z3jiang

z3jiang Mar 26, 2012

+1

z3jiang commented Mar 26, 2012

+1

@avernet

This comment has been minimized.

Show comment Hide comment
@avernet

avernet Mar 29, 2012

+1

avernet commented Mar 29, 2012

+1

ebruchez added a commit to orbeon/junit that referenced this issue Mar 30, 2012

Add names for parameterized tests. Fixes #24 and #44.
In order that you can easily identify individual test, you may provide
a name for the Parameters annotation.
 @Parameters(name="my test")
This name is allowed to contain placeholders, which are replaced at
runtime. The placeholders are
* {index} - the current parameter index
* {0} - the first parameter
* {1} - the second parameter
* ... - the other parameters
If you don't use the name parameter, then the current parameter index
is used as name.

Example:
When you use @Parameters(name="fib({0})={1}") with the Fibonacci
example, then you get test names like "fib(3)=2".

This feature is based on the work of Dimitar Dimitrov (pull request
#145).
Thank
you.

dsaff added a commit that referenced this issue Apr 9, 2012

Merge pull request #393 from stefanbirkner/Parameterized
Add names for parameterized tests. Fixes #24 and #44.
@guyburton

This comment has been minimized.

Show comment Hide comment
@guyburton

guyburton Apr 12, 2012

+1 we have used a fork of Parameterized to implement this feature. We have also made the TestClassRunnerForParameters protected, and it is created by a protected method to allow extension of Parameterized within another implementation of Suite.

+1 we have used a fork of Parameterized to implement this feature. We have also made the TestClassRunnerForParameters protected, and it is created by a protected method to allow extension of Parameterized within another implementation of Suite.

@stefanbirkner

This comment has been minimized.

Show comment Hide comment
@stefanbirkner

stefanbirkner Apr 12, 2012

Contributor

The feature is implemented. See #393.

@dsaff Could you please close the issue.

Contributor

stefanbirkner commented Apr 12, 2012

The feature is implemented. See #393.

@dsaff Could you please close the issue.

@dsaff

This comment has been minimized.

Show comment Hide comment
@dsaff

dsaff Apr 12, 2012

Owner

Done.

Owner

dsaff commented Apr 12, 2012

Done.

@dsaff dsaff closed this Apr 12, 2012

@java-artisan

This comment has been minimized.

Show comment Hide comment
@java-artisan

java-artisan Apr 23, 2012

Many thanks indeed ! :-)

Many thanks indeed ! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment