Parameterized runner should name tests better than sequential numbers

[anshnd]

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]

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

Thanks, Jörg

[JThoennes]

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

[jjunit2010]

Any more news on when this fix might be implemented?

[reccles]

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]

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]

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]

See http://github.com/ralfebert/junit/commit/d5fedb0

[JThoennes]

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

And when will the next release happen?

[davidkarlsen]

+1

[kaipe]

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.

[alexeyOnGitHub]

the source code posted here worked perfectly http://stackoverflow.com/questions/650894/change-test-name-of-parameterized-tests

here are the direct links to the source code:

http://code.google.com/p/migen/source/browse/trunk/java/src/uk/ac/lkl/common/util/testing/LabelledParameterized.java?r=3789

http://code.google.com/p/migen/source/browse/trunk/java/src/uk/ac/lkl/common/util/restlet/test/builder/ServerBuilderTest.java?r=3789

[mmakowski]

+1

[soehalim]

+1

[elygre]

+1

[binkley]

+1

[davidkarlsen]

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]

+1

[joelmheim]

+1

[stefanbirkner]

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]

+1

[stefanbirkner]

I'm just waiting for pull request #348

[bsbodden]

+1

[RaviH]

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

[Tibor17]

+1

[Jeanguitoune]

+1

[yurodivuie]

+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]

+1

[sharfah]

+1

[cwhite102]

+1

[veger]

+1

[java-artisan]

+1

[lbuchy]

+1

[mrmanc]

+1

[ghost]

+1

[mariusx]

+1

[jpfielding]

+2

[z3jiang]

+1

[avernet]

+1

[guyburton]

+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]

The feature is implemented. See #393.

@dsaff Could you please close the issue.

[dsaff]

Done.

[java-artisan]

Many thanks indeed ! :-)