When working on WorkflowJBPMModuleVersionHandlerTestCase, I noticed a few weird behaviors. See MAGNOLIA-5170.

Some more "interesting" observations that may or may not be related, but are probably due to other bugs in MgnlTestCase, RepositoryTestCase etc:

• In my test, only the 2nd test method would fail, from the setUp, due to the imaging component being registered twice. Consequently, the tearDown would also fail, claiming a SystemContext impl isn't registered (which is what led me to the 2nd workaround)
• When adding the following in my test class, both test methods would fail the same way, which leads me to believe there are other bugs in the setup/teardown of our abstract test classes.

      @Override
      @Before
      public void setUp() throws Exception {
          SystemProperty.clear();
          ComponentsTestUtil.clear();
          super.setUp();
      }
  

• When running through the various setUp() methods (MgnlTestCase, RepositoryTestCase, ModuleVersionHandlerTestCase, I noticed that info.magnolia.cms.core.SystemProperty#magnoliaConfigurationProperties was swapped a number of times, making it hard to reliably know what properties are currently configured.

In general, I'm not sure we should even try to fix this, because it's really all using legacy code. The abstract/parent test clases are of course still useful, to provide Magnolia-specific helpers, or setup a repository, but they could be simplified by properly making use of IoC (i.e by not relying on properties and configured singletons, but by manually assembling the components it needs). This would impact the production code as well as the test framework.

Things like LegacyComponentProvider should probably not be used in newer tests, but they still do, because we tend to keep on using the same patterns as we used in the days of MgnlTestCase.