| Newsgroups |
gmane.comp.java.junit.user,gmane.spam.detected |
| Message-ID |
<[email protected]> |
@Esko Good point.
@all It's important do differentiate between junit4 and junit5 -
regarding junit4 I have had bad experiences regarding compatibility.
Therefore I fear that this separation might cause compatiblity problems
for junit4 users. Stefan Birkner has sent his email to the junit mailing
list and Nat Pryce's sample project is about separating junit4 and
hamcrest. Thus I assumed we were talking about the next (or some future)
Junit4 release.
Regarding JUnit5 the separation makes more sense but should be supported
by a committment to compatiblity and extensibility. I think there is a
broad agreement that JUnit5 should concentrate on the aspects of running
tests but needs to be extensible and needs to provide hooks for other
projects like test-starters (IDE, maven surefire, pitest ....), test
result reporters (IDE, maven surefire, CI server plugins, sonar qube,
...), test environment enhancers (Spring, JMock, Arquillian and all the
others that have custom runner implementations) and many more. But as
more and more projects will use these hooks they have to be reliable and
stable (at least across minor releases).
I tried to keep it short and will continue discussion at the mailing list.
Stefan
Am 12.01.2015 um 17:26 schrieb Esko Luontola [email protected]
[junit]:
> Some time ago the testing-java-8 mailing list was started to discuss
> things like these; to throw around ideas about new testing frameworks
> and tools in the post-Java 8 world, without cluttering the JUnit mailing
> list with non-JUnit stuff.
>
> https://groups.google.com/forum/#!forum/testing-java-8
>
>
> Stefan Bechtold [email protected] [junit] wrote on 12.1.2015 13:53:
>> Concerning the exception handling, I like the JUnit Rule based approach for applications up to Java 7 (without support for lambdas) very well. This provides a way to execute a piece of code and provide information about the code that was executed. In order to be compatible to Java 7 (and maybe 6), I think it is a must-have feature in the next testing framework. Anyways, wherever possible, I would strongly recommend to leave the assertion part out of the test framework and simply provide an extension point (like the @Rule annotation) for 3rd party libraries. For Java 8, I really prefer the lambda approach, as it makes the test code much more readable and expresses the intend of the test case more clearly.
------------------------------------
------------------------------------