Hi Johannes. I am not a committer on the Surefire plugin but I wanted to offer my opinion anyway to you.
I took a look at JUnit 5 API. My only criticism is the @Context annotation. I don't think developers should be encouraged to write inner classes for the sake of grouping tests. I believe this has already been sufficiently covered with the use of the new @Tag and/or by method naming conventions (like testWithChild1, testWithChild2, etc.). Furthermore, JEE has already has an established @Context annotation in many of the EE specs which are associated with dependency injection. I think it's a bit jaring to see JUnit's @Context be so different. My advice is to either drop @Context (I don't like it's current meaning) or re-purpose it to be part of dependency injection -- possibly completely replacing the @Named injection and giving one common object to retrieve whatever you need to know about the test execution context/metadata. Cheers, Paul On Wed, Nov 18, 2015 at 2:18 AM, Andreas Gudian <[email protected]> wrote: > Forwarding to dev@ > > ---------- Forwarded Message ---------- > From: *Johannes Link* <[email protected]> > Date: 18/11/2015 > Subject: Open Test Alliance > > > Hi you all, > > I'm writing to you in your roles as committers to the maven sure-fire > plugin. Since we couldn't figure out the "main contributors" (in case > you have such a thing), I randomly picked a few from: > https://maven.apache.org/surefire/maven-surefire-plugin/team-list.html > Maybe we can communicate through just one or a few people later, if > necessary. If the right person is not in the list, please forward the > email or let me know who I should contact. Let's get to the point: > > We, the JUnit Lambda team, are reaching out to you for collaboration > on an initiative we are tentatively calling the Open Test Alliance. > > As we all know, there is no standard for testing on the JVM. The only > common building block we have is java.lang.AssertionError. That's > great for signaling that a test has failed, but it doesn't go far > enough. Each testing framework is therefore forced to fill the gap > with custom subclasses of AssertionError or RuntimeException to > provide a richer feature set to end users. The downside is that each > framework has its *own* set of custom errors and exceptions, and this > makes it a challenge for frameworks to interoperate. For example, > JUnit has long supported the notion of a failed assumption via its > AssumptionViolatedException, but assertion frameworks like AssertJ > cannot integrate that feature without a direct dependency on JUnit. > Furthermore, the status quo makes the work of IDE and build tools more > difficult than it should be. > > The solution is to create a foundation that we can all build on! > > Based on recent discussions with IDE and build tool developers from > Eclipse, Gradle, and IntelliJ, the JUnit Lambda team has developed a > proposal for an open source project to provide a minimal common > foundation for testing libraries on the JVM. The primary goal of the > project is to enable testing frameworks like JUnit, TestNG, Spock, > etc. and third-party assertion libraries like Hamcrest, AssertJ, etc. > to use a common set of exceptions that IDEs and build tools can > support in a consistent manner across all testing scenarios -- for > example, for consistent handling of failed expectations and failed > assumptions as well as visualization of test execution in IDEs and > reports. > > We have already begun with a small set of errors and exceptions that > we consider to be common for all testing and assertion frameworks. In > fact, we are already using these exceptions in the JUnit Lambda > Prototype [1]. > > Please take a look at our current draft in the open-test-alliance [2] > project and let us know what you think. > > Furthermore, in order to foster open discussions, we have created a > GitHub issue [3] where you are welcome to comment and collaborate. > > We look forward to your feedback and encourage you to join us in this > initiative to make testing easier for everyone on the JVM. > > Best regards, > > Johannes, in the name of the JUnit Lambda Team > > > [1] https://github.com/junit-team/junit-lambda/wiki/Prototype > [2] > https://github.com/junit-team/junit-lambda/tree/master/open-test-alliance > [3] https://github.com/junit-team/junit-lambda/issues/12 >
