Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Tibor17
Copy link
Contributor

@Tibor17 Tibor17 commented Mar 5, 2022

The plugin does not have a real problem with the class path as we expected in the Jira issue SUREFIRE-2000.
I found this PR as an improvement where the junit-platform-runner can be in the plugin dependencies. The previous implementation expected junit-platform-runner only in the project dependencies. Additionally, we added junit-platform-suite-engine as a successor of junit-platform-runner in the documentation and IT.

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace SUREFIRE-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in the pull request title and in the first line of the
    commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean install to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.
  • You have run the integration tests successfully (mvn -Prun-its clean install).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

Comment on lines 80 to 87
//args.add( new Object[] {"1.1.1", "5.1.1", "1.0.0", "1.0.0"} );
//args.add( new Object[] {"1.2.0", "5.2.0", "1.1.0", "1.0.0"} );
args.add( new Object[] {"1.3.2", "5.3.2", "1.1.1", "1.0.0"} );
args.add( new Object[] {"1.4.2", "5.4.2", "1.1.1", "1.0.0"} );
args.add( new Object[] {"1.5.2", "5.5.2", "1.2.0", "1.1.0"} );
//args.add( new Object[] {"1.4.2", "5.4.2", "1.1.1", "1.0.0"} );
//args.add( new Object[] {"1.5.2", "5.5.2", "1.2.0", "1.1.0"} );
args.add( new Object[] {"1.6.2", "5.6.2", "1.2.0", "1.1.0"} );
//args.add( new Object[] { "1.6.0-SNAPSHOT", "5.6.0-SNAPSHOT", "1.2.0", "1.1.0" } );
//args.add( new Object[] {"1.7.2", "5.7.2", "1.2.0", "1.1.0"} );
args.add( new Object[] {"1.8.2", "5.8.2", "1.2.0", "1.1.2"} );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dead code should be removed ... or commented why and when we want to restore it.

Copy link
Contributor Author

@Tibor17 Tibor17 Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My motivation was to remove some config because the build takes long with every next config, and these configs have been tested already long enough in our tests, and the new ones have not been tested yet.

Comment on lines 414 to 458
** JUnit5 Suite

For more information see this
{{{https://github.com/apache/maven-surefire/tree/master/surefire-its/src/test/resources/junit5-suite}example}}.

+---+
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-suite-api</artifactId>
<version>1.8.0</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>JUnit5Tests</include>
</includes>
</configuration>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.8.2</version>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-suite-engine</artifactId>
<version>1.8.2</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like next complicated ... why dependency in project and plugin
Even if we we support it in code for some reason we shouldn't give such examples ... project dependency should be enough.

Maybe we should also link to JUnit documentation.
https://junit.org/junit5/docs/current/user-guide/#junit-platform-suite-engine

Copy link
Contributor Author

@Tibor17 Tibor17 Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because there are more alternatives. So the JUnit5 team separated API from impl and they always stated that the user does not need to access the impl of the engine.
If you like I put engines to the dependencies. Both would work. It's just matter of taste.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO the users don;t care if they have an access to the engine internals. So I wil use only project deps. thx

Copy link
Member

@olamy olamy Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @slawekjaranowski such extra configuration complexity will be confusing for users. and if given as an example in the users documentation the users will simply copy/paste this over complicated configuration whereas they might not need it.

@Tibor17
Copy link
Contributor Author

Tibor17 commented Mar 5, 2022

@slawekjaranowski
done

Comment on lines +421 to +434
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.8.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-suite-engine</artifactId>
<version>1.8.2</version>
<scope>test</scope>
</dependency>
</dependencies>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure if we want to write documentations for external products .... 😄
But from other side we should be consistent with original product
documentation.
https://junit.org/junit5/docs/current/user-guide/#junit-platform-suite-engine-setup-required-dependencies

There is:

Required Dependencies

  • junit-platform-suite-api in test scope: artifact containing annotations needed to configure a test suite
  • junit-platform-suite-engine in test runtime scope: implementation of the TestEngine API for declarative test suites

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slawekjaranowski
Slawomir, we have never repeated "their" documentation. We have always declared Surefire configuration in order to run some tests, support some framework, declaring features we support and we made a fix to support these features.
The JUnit documentation should mentioned us as Surefire, we have to do it, we are the one who should understand how the framework works and how it should be used and configured in the Surefire/Failsafe, not opposite.

<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>JUnit5Tests</include>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I afraid that users can simply comply such configurations .... and will be surprised

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't be surprised! What is the point of Junit5 Suite? It's the same point that the Junit4 suite has!
The Point is to start the suite class which is a similar case is in your Surefire project. The suite children are executed by selecting JUnit5Tests and not by surefire provider and that the reason you have to select it. You must select the suite and not the children. Why we do not use the parameter test? Because there is a significant difference between includes and test. The test is a filter performing the selection inside of the JUnit which cannot be used here because this way you are not able to select the root class JUnit5Tests and you filter out all children. The includes does exactly what we want, it does not perform filtering inside of JUnit, it performs selection of classes that you send to the JUnit framework to execute it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

such explanation should be put in example,
what inclusion is for and what value should contains.

<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.8.2</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does should be the same version as for api?
the same for suite-api and suite-engine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants