With the current approach of checking log entries we are not able to
check log entries in case of a failure. But is is important to assert
log messages in case of a failure. Having reasonable log messages
simplified troubleshooting.
Hence we add JenkinsLoggingRule.expect(substring) and check after the
base of that rule has been called.
This interfears with other rules also working with an expect approach,
like e.g. ExpectedException. Which violation is presented depends on
the order or the rules around the test case.
Comparism on plain string level gets complicated for complex commands and means
an implict check for an exact version of a command line. There are cases where
such an exact check is not desired, e.g. there is nothing wrong with having the
order of arguments variable.
Starting point for that refactoring: it turned out that the tests
was not independent. The DefaultValueCache which is a singleton
keeps the status over various tests. Success of test execution depends
on the order test execution.
We have now
* a dedicated rule for resetting the default value cache
* JenkinsConfiguration rule (which already provided facilities for
dealing with the configuration) has been replaced by a readYaml rule.
From the PipelineUnit test framework we get already a handler for
libraryResource, which is also part of the setup of the default
values.
* An auxiliar class which combines the
* JenkinsSetupRule (registers the lib)
* JenkinsReadYamlRule (provides facilities for Yaml parsing)
* JenkinsResetDefaultValueCacheRule (cleans up the DefaultValueCache)
into a rule chain. By using this rule chain we ensure that our
setup OK (piper lib registered, and default config can be setup in
a clean way).
