Why they added a @DisplayName and didn't add a param to @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:
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.
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.
SpringExtension is available since Spring 5 not Spring boot 2. This class can be found in spring-test dependency.
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.
what is an Excpeiton?
An Exception is when your code try to do something and this something goes wrong. That "something" sends you an Exception, so you can see what did wrong and treat your code correctly.
You can see in a more tecnical and detailed way here: docs.oracle.com/javase/tutorial/es...
I don't know.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.