Junit5: Have @Tags take String[]

[mickeelm]

While there is great strength in that @Tag is @Repeatable and I'm grateful for that, I find it a bit unfortunate that @Tags is the containing annotation type for @Tag. I'd like the opportunity to write multiple tags in a single annotation in order to reduce some lines. And while it's of course possible to write @Tags({@Tag("a"), @Tag("b"), @Tag("c")}) it looks messy and @Tags({ "a" , "b", "c" }) would definitely be preferrable.

Meta-annotations are neat when the tag values are _static_, but for instance if they are unique for each test (ticket ids, requirement ids and so forth) then that's not gonna work.

So, I'd like the @Tags type that exists now (i.e. the containing annotation of @Tag) to be named something else (@TagContainer?), and instead have @Tags taking an array of Strings. It seems natural/intutive to me and was certainly what I expected when I first saw the annotation. I realize that it would maybe lead to a kind of not so nice deprecation-scenario, but the question is how many people there are out there that actually use @Tags today, given that it's just a container type.

[marcphilipp]

Team decision: Before exploring how to implement this feature, we'd like to see if there's additional interest from the community.

[sormuras]

As written over here https://gitter.im/junit-team/junit5?at=5e3a43f0d9895b17c3d073d4 I'm fine with the status quo (and language default) to have multiple tags attached to an element without using the collecting @Tags annotation explicitly:

@Tag("a") @Tag("b") @Tag("c") // single line, three annoations
void test() {}

Or in a condensed and reusable form:

@AlphabetTags // single line, single annotation
void test() {}

// with a composed annotation declared as

@Retention(RetentionPolicy.RUNTIME)
@Tag("a") @Tag("b") @Tag("c")
public @interface AlphabetTags {}

[sormuras]

Having said that, I'd suggest to explore the declaration and usage of more targeted annotations for specific use-cases, like _"ticket ids, requirement ids and so forth"_.

Something like this https://github.com/junit-pioneer/junit-pioneer/issues/135 - "Add declarative annotations for "issue" type support and infrastructure"

[mickeelm]

I just need to clarify some.

As written over here https://gitter.im/junit-team/junit5?at=5e3a43f0d9895b17c3d073d4 I'm fine with the status quo (and language default) to have multiple tags attached to an element without using the collecting @Tags annotation explicitly:

I 100% agree on the without part, and I guess I've been unclear here. I'm not using @Tags, what I'm using now is indeed repeated @Tags.

Just to be clear, with these three alternatives (the fourth, using @Tags as a containing annotation type is probably not a realistic option):

1:

@Test
@Tag("TYPE_BAD_JSON")
@Tag("REQ-112")
@Tag("TICKET-123")
@DisplayName("Calling endpoint e with badly formatted JSON should return a 400")

2:

@Test
@Tag("TYPE_BAD_JSON") @Tag("REQ-112") @Tag("TICKET-123")
@DisplayName("Calling endpoint e with badly formatted JSON should return a 400")

3:

@Test
@Tags({"TYPE_BAD_JSON", "REQ-112", "TICKET-123"})
@DisplayName("Calling endpoint e with badly formatted JSON should return a 400")

I would prefer #3 and that's the first reason why I raised the ticket. The second reason is that I simply expected @Tags to take String[], i.e. it was my first thought when browsing the API looking for the possibility to do #3 and I was surprised to find that it wasn't implemented that way. So, IMO this change would make the API better in a "does what you expect it to"-way.

[sbrannen]

So, I'd like the @Tags type that exists now (i.e. the containing annotation of @Tag) to be named something else (@TagContainer?), and instead have @Tags taking an array of Strings. It seems natural/intutive to me and was certainly what I expected when I first saw the annotation. I realize that it would maybe lead to a kind of not so nice deprecation-scenario, but the question is how many people there are out there that actually use @Tags today, given that it's just a container type.

That is unfortunately not an option since it would be a breaking change both in terms of source and binary compatibility.

If we were to implement the requested feature, I think we would likely want to introduce a second attribute in @Tag alongside value -- for example, group (for lack of a better name off the top of my head). Those two attributes would then be mutually exclusive, and use of both in the same annotation would result in a configuration exception.

[mickeelm]

Given this information, IMO this ticket can be closed (I don't know how the routines are, should I close or a maintainer?).

[sbrannen]

Well, since you opened the ticket, @mickeelm, you may choose to close it on your own.

But I'll close it for you now.

The ticket will of course remain intact. Thus the community may still comment on the feature, and the ticket could be reopened at a later date if necessary.