When I have a test like this:
```kotlin
@RunWith(TestParameterInjector::class)
class ParameterizedTest {
@Test
fun `test something`(
@TestParameter protocol: ProtocolVersion,
@TestParameter ui: UiVersion,
) = Unit
}
enum class ProtocolVersion {
V1, V2
}
enum class UiVersion {
V1, V2
}
```
it's a bit hard to differentiate the tests based solely on their names:
```
test something[V1, V1]
test something[V1, V2]
test something[V2, V1]
test something[V2, V2]
```
I'd like to have a way to specify how the output should look, for example something like this:
```
test something[protocol=V1, ui=V1]
test something[protocol=V1, ui=V2]
test something[protocol=V2, ui=V1]
test something[protocol=V2, ui=V2]
```
Currently, the only workaround I know of is to rename the enum values themselves, which isn't always desirable:
```kotlin
enum class ProtocolVersion {
ProtocolV1, ProtocolV2
}
enum class UiVersion {
UiV1, UiV2
}
```
Hi Michał,
There is no such feature today and I based on my current experience and feedback, I don't think adding this feature would be worth the weight it adds to the learning curve/API surface.
As an alternative, can you do something like this?
```
enum class UiVersion {
V1, V2;
override fun toString() = "UiVersion.$name"
}
```
It feels like that `toString` would be useful beyond tests too.
@nymanjens I tried `toString()` before but it doesn't work unfortunately.
https://github.com/google/TestParameterInjector/blob/cef221461f533262be22017e880a254cdce67281/junit4/src/main/java/com/google/testing/junit/testparameterinjector/ParameterValueParsing.java#L391-L394
> I don't think adding this feature would be worth the weight it adds to the learning curve/API surface.
`@TestParameters` has a `customName` property. Would it be that much more of a learning curve?
But I'm not necessarily asking for that. Respecting `toString()` would be enough. I'd be happy to make a PR if you're open to that. Or to include the parameter name in the test name just like other types do.
You're right, `toString()` doesn't work. I tried to locally change `name()` to `toString()` and it broke ~100 tests (some of our tests depend on the test name, which is easy enough to fix but it indicates a backwards incompatible change). Looking at them individually, the change to `toString()` was usually for the worse.
So that's probably not a great idea.
Including the parameter name is not great either because of
- A/ it is also backwards incompatible (on a much greater scale)
- B/ it is very deliberate that we're omitting the field name because most enum values are self-explanatory (no need for `fruit=` in `fruit=APPLE`)
So that leaves a `customName`-type solution. E.g.
```
@Test
void myTest(@TestParameter(customName="Fruit.%s") Fruit fruit) {..}
```
This is a small increase in overall complexity/learning curve/API surface. The thing is that if this is only useful for a tiny amount of use cases, it is not worth it. Over the years, I have considered dozens of requests just like this and rejected many. If we had added all of them, I believe the combined weight would make the whole TestParameterInjector tool less attractive.
I propose keeping a note of this request and if it turns out others also want this, then that would make a stronger case to add this.
No worries, I understand. If you think that it can muddy the API too much for little benefit that's ok. I just wanted to follow up because the `toString()` suggestion doesn't work and I wasn't sure if that's expected or not.