Introduce tests for the Gradle plugin #63
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hello Cedric Champeau, thanks for contributing a PR to our project! We use the Oracle Contributor Agreement to make the copyright of contributions clear. We don't have a record of you having signed this yet, based on your email address cedric -(dot)- champeau -(at)- gmail -(dot)- com. You can sign it at that link. If you think you've already signed it, please comment below and we'll check. |
melix
force-pushed
the
cc/introduce-tests
branch
2 times, most recently
from
fba416d
to
c42b6bd
Compare
This commit introduces functional tests for the Gradle plugin. For now, it's limited to a single test but it will be expanded for more use cases. Functional tests are using samples found in the `src/samples` directory. There are 2 test tasks which can be executed, depending on whether you want full test coverage or not: - `functionalTest` will run the test suite on the current version of Gradle only - `fullFunctionalTest` will do the same, but on all supported Gradle versions To make this possible, the build has been reorganized to leverage Gradle composite builds, instead of using the local Maven repository. Previously to this, it was necessary to cd into `junit-platform-native`, publish to maven Local, then go to the Gradle plugin, build it, and test with a local project. This is no longer required, as now the execution of functional tests will _automatically_ trigger the build of the native JUnit project, publish the library to a _test_ repository, which in turn is used by the functional tests (via repository injection in an init script). This makes it impossible to make mistakes, or have the build fragile if you don't build the `junit-platform-native` first: the dependency is now explicit.
That is to say that this test verifies that we can: - build an image which contains production code and test code - execute this image which results in tests being executed
The sample now expects the JUnit version to be injected via a system property. This will allow consistent upgrades of libraries without having to update the samples themselves.
melix
force-pushed
the
cc/introduce-tests
branch
from
c42b6bd
to
ab97f0f
Compare
This is really a simple verification at this stage, on the top-level test suite only. In particular this is likely not to work for more test cases since Gradle would issue one test result file per test, while native-test would use a single one.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please refer to the commit messages for details. Basically I'd like to refactor the plugin a bit before it goes 1.0. But before doing those refactorings, I would like to have minimal test coverage to make sure I don't break anything.
This PR therefore introduces tests and fixtures to make it easy to do so.