Since JenkinsRule was created (one year ago from tomorrow!) as a clone of HudsonTestCase for JUnit 4, the two have diverged subtly. For example, olamy’s 39b743d touched
HTC but not JR, and the same is true of several commits by kutzi, at least one by slide.o.mix, and probably others. Clearly it is not acceptable to have significant
duplicated code like this with no clear synchronization.
Assuming that the goal is to make HTC be @Deprecated to encourage tests to migrate to JR/JU4, with HTC ultimately being a compatibility shell only for old tests, what is
the best way to proceed?
My thought was to introduce a JR-valued field into HTC, calling its initialization & teardown methods at the appropriate times; delete other private fields in HTC,
rewriting HTC code to match; deprecating other protected or public fields in HTC, copying their values from JR when appropriate, with special handling for fields which
are not intended to be “effectively final” (*); and incrementally replacing the bodies of HTC methods with calls to the analogous method in JR, updating that method in JR
when the HTC version seems newer. Some other tricks would be needed to handle nested types like WebClient & TestBuildWrapper, perhaps making the HTC version be a no-op
subclass of the JR version.
Anyone know of a reason why this kind of refactoring would not work, or not be
desirable to begin with?
(*) Exposing fields from an API is a terrible practice but too late now for HTC. Unfortunately this bad habit was carried over into JR as well, though there are probably
few enough clients of JR at this point that incompatible changes could be made. (Would be great to have a Sorcerer site published covering all main and test classes in
core and all plugins, so that we could run Find Usages easily.)
