Gradle plugin demo where the functional tests have no access to the plugin or the testing project classpath
This plugin accepts a configuration of the following form and echoes the contents of the specified file in the Standard output.
echofiletask{
filePath = "echo.me"
}
./gradlew build
- The
plugin
folder contains the implementation logic of the plugin. - The
main
folder contains hte main implementation logic - The
test
folder contains Unit tests for the various modules of the plugin - The
functionalTest
folder contains tests that invoke a GradleRunner and test the total result of the plugin application.
- It is important to note that in the
test
folder we cannot instantiate the Tasks that we create and therefore we can only test logic that is connected to the project structure, i.e., whatever one can define withing the filesbuild.gradle
andsettings.gradle
. If the plugin task interacts with some project files (of the testing project), we can test such interactions with the functional tests.
2.Given the current setup, it is not possible for the functional tests to have access to the
classpath of the main
or the test
folder. That is to say, the functional tests observe only
the results of the build that is run by the GradeRunner
This folder contains a separate and independent project that is copied during the functional tests
to a temporary folder and GradleRunner
runs on this temporary folder.
It is necessary to inject a settings.gradle
file and it is possible to inject any other file
that is necessary for the functional tests.
- No other module or code in any of the
plugin
folders have access to the classpath of thetestingProject
. Dependency to thetestingProject
's classpath seems very difficult to accomplish without having synchronization problems. - The
testingProject
is connected to the plugin through the configuration of itssettings.file
and can be run normally as an independent project,gradle build
is run inside thetestingProject
This implementation is based on the default Gradle plugin setup.