This change simplifies test generation, adds test coverage, makes use of lazy configuration, and isolates generated tests for less surprising behavior.
Test generation is disabled by default before and after this change.
insertTest task has been replaced by generateJenkinsTests
jenkinsPlugin.requirePI is now a fallback for jenkinsPlugin.requireEscapeByDefaultInJelly
jenkinsPlugin.disabledTestInjection is now a fallback for jenkinsPlugin.generateTests
jenkinsPlugin.injectedTestName is now a fallback for jenkinsPlugin.generatedTestClassName
Test Task
test now depends on generateTestHpl, which is needed for running @JenkinsRule tests that expect the plugin to be installed. There is now a test verifying this works as expected, which revealed that the jcip-annotations and findbugs both need to be on the testCompileOnly classpath to avoid compiler warnings.
Previously testClasses depended on generateTestHpl, but the hpl is needed for running the tests, not generating them.
This should reduce the amount of prior knowledge needed to write plugins. For example, I have been using JUnit 5 for unit tests for a long time, not realize that this would skip the generated tests unless I explicitly included the junit-vintage-engine. That's no longer the case with a dedicated task.
GenerateJenkinsTests Task
Formerly the insertTest task, this now models the generated class with the excellent JavaPoet library. The generated class has a test that compiles it with -Werror to ensure we don't generate with warnings.
This task is implemented using the worker api, just like the checkAccessModifier task introduced in #162. The benefit of this approach is using an isolated classpath that does not leak dependencies on the buildscript classpath.
GeneratedJenkinsTest Task
This task is newly introduced. check depends on generatedJenkinsTest, so it will be run with a typical build. This task also depends on generateJenkinsTests. Like with the test task:
buildDirectory system property is set for the jenkins-test-harness
generateTestHpl is an input that is added to the execution classpath
tests were added to ensure it passes and fails as a plugin developer would expect
Having an isolated test task for the generated tests improves things in a couple ways:
It's always setup to use JUnit 4, which is required to run these tests
It has its own configuration, so no surprising dependency conflicts can inadvertently creep in
This change simplifies test generation, adds test coverage, makes use of lazy configuration, and isolates generated tests for less surprising behavior.
Test generation is disabled by default before and after this change.
insertTesttask has been replaced bygenerateJenkinsTestsjenkinsPlugin.requirePIis now a fallback forjenkinsPlugin.requireEscapeByDefaultInJellyjenkinsPlugin.disabledTestInjectionis now a fallback forjenkinsPlugin.generateTestsjenkinsPlugin.injectedTestNameis now a fallback forjenkinsPlugin.generatedTestClassNameTest Task
testnow depends ongenerateTestHpl, which is needed for running@JenkinsRuletests that expect the plugin to be installed. There is now a test verifying this works as expected, which revealed that the jcip-annotations and findbugs both need to be on thetestCompileOnlyclasspath to avoid compiler warnings.Previously
testClassesdepended ongenerateTestHpl, but the hpl is needed for running the tests, not generating them.This should reduce the amount of prior knowledge needed to write plugins. For example, I have been using JUnit 5 for unit tests for a long time, not realize that this would skip the generated tests unless I explicitly included the junit-vintage-engine. That's no longer the case with a dedicated task.
GenerateJenkinsTests Task
Formerly the
insertTesttask, this now models the generated class with the excellent JavaPoet library. The generated class has a test that compiles it with-Werrorto ensure we don't generate with warnings.This task is implemented using the worker api, just like the
checkAccessModifiertask introduced in #162. The benefit of this approach is using an isolated classpath that does not leak dependencies on the buildscript classpath.GeneratedJenkinsTest Task
This task is newly introduced.
checkdepends ongeneratedJenkinsTest, so it will be run with a typical build. This task also depends ongenerateJenkinsTests. Like with thetesttask:buildDirectorysystem property is set for thejenkins-test-harnessgenerateTestHplis an input that is added to the execution classpathHaving an isolated test task for the generated tests improves things in a couple ways:
Fixes #180 Related to #125