Ha! That's a very good question that I just recently asked Sam Brannon, one of the core committers of JUnit 5. :)
His answer goes as follows:
There are other "things" that support @DisplayName like test class (as shown in my example), @TestFactory, @RepeatedTest, @ParameterizedTest and @TestTemplate. Having @DisplayName orthogonal to those features is just about separating concern.
If JUnit would have a concept like @AliasFor meta annotations in spring, ´this would still be possible (but it doesn't)
You could write your own custom composed annotation
An intuitive method/function name is vital in every language, if it's not enough we got documentation and if we got access to source, inner comments too. DisplayName is the excuse to avoid all previous Nested your example just add more pollution, it is not a good one PD: I like tests ;)
Honestly, I don't really understand your point. Sure, functional readable method names are important. But why would anyone stop doing that in favor of using @DisplayName? Is this just your hypothesis or did you actually see that?
Testing is not about how the code works but what it should do. This you won't get from looking at the code. Tests are the functional specification written in your language of choice. Having @DisplayName just makes this specification more readable.
As I pointed out already, @Nested is more "pollution", however when you execute the tests and you see them properly grouped and named in the IDE, it is very helpful.
I was looking at this from a spring-boot perspective (maybe a bit narrow-minded) where you don't select the spring framework or testing version anymore. Spring 5 will be used by boot 2 automatically.
First, it's not necessary but your IDE will probably warn you (e.g. IntelliJ does it). Second, yes it's just less boilerplate. But I intentionally did not try to communicate that a must-have feature.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why they added a @DisplayName and didn't add a param to @test like @test (name = "it should not fails")?
Ha! That's a very good question that I just recently asked Sam Brannon, one of the core committers of JUnit 5. :)
His answer goes as follows:
@DisplayNamelike test class (as shown in my example),@TestFactory,@RepeatedTest,@ParameterizedTestand@TestTemplate. Having@DisplayNameorthogonal to those features is just about separating concern.@AliasFormeta annotations in spring, ´this would still be possible (but it doesn't)An intuitive method/function name is vital in every language, if it's not enough we got documentation and if we got access to source, inner comments too. DisplayName is the excuse to avoid all previous
Nested your example just add more pollution, it is not a good one
PD: I like tests ;)
Honestly, I don't really understand your point.
Sure, functional readable method names are important. But why would anyone stop doing that in favor of using
@DisplayName? Is this just your hypothesis or did you actually see that?Testing is not about how the code works but what it should do. This you won't get from looking at the code. Tests are the functional specification written in your language of choice. Having
@DisplayNamejust makes this specification more readable.As I pointed out already,
@Nestedis more "pollution", however when you execute the tests and you see them properly grouped and named in the IDE, it is very helpful.Amazing. I really like the idea of giving names to the tests. The tests that I did always ended up as you said, with bigger names.
SpringExtensionis available since Spring 5 not Spring boot 2. This class can be found inspring-testdependency.Yep, you are right.
I was looking at this from a spring-boot perspective (maybe a bit narrow-minded) where you don't select the spring framework or testing version anymore. Spring 5 will be used by boot 2 automatically.
What does not making methods and classes public buy us? Better readability?
First, it's not necessary but your IDE will probably warn you (e.g. IntelliJ does it). Second, yes it's just less boilerplate. But I intentionally did not try to communicate that a must-have feature.