Junit5 support  #94

Activity

1. jschmied commented on Sep 18, 2023

   

   jschmied

   on Sep 18, 2023

   More actions

   We migrate to JUnit5 also, support would be nice
2. SirSoySauce commented on Oct 28, 2024

   

   SirSoySauce

   on Oct 28, 2024

   More actions

   As upgrading to JUnit 5 was a priority for us, we implemented a custom solution to overcome this issue. Unfortunately, because the impact of the solution affects more than just the GwtMockito test classes (and we removed all code that is not relevant for our project), it is not really suitable to create a PR for it.

   If any of the following is incorrect, or you see a better solution, feel free to correct me! This is what we came up with after some trial and error, it is possible that there is a better solution out there.

   The way GwtMockito works with JUnit 4, is replacing the test class itself with a custom loaded version of it (and setting a custom ClassLoader for the rest of the test). This can be seen in the GwtMockitoTestRunner implementation:

   // Use this custom classloader as the context classloader during the rest of the initialization
   // process so that classes loaded via the context classloader will be compatible with the ones
   // used during test.
   ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
   Thread.currentThread().setContextClassLoader(gwtMockitoClassLoader);
   ...
   Class<?> customLoadedTestClass = gwtMockitoClassLoader.loadClass(unitTestClass.getName());
   testClassField = ParentRunner.class.getDeclaredField("testClass");
   testClassField.setAccessible(true);
   testClassField.set(this, new TestClass(customLoadedTestClass));
   

   With JUnit 4, you could overwrite the default test Runner with the @RunWith annotation on a test class. In JUnit 5, this mechanic got replaced by Extensions (@ExtendWith annotation). With JUnit 5, we therefore need a different way to overwrite the ClassLoader for test classes.

   In our approach, we use a custom LauncherInterceptor. The problem with this is, that the ClassLoader gets applied to all test classes in the affected module. To mitigate this issue, we put all GwtMockito test classes into one module and only applied the changes to those.

   With this, you can more or less reuse the GwtMockito-Junit 4 code. All the new GwtMockitoExtension need to do is initializing the mocks. Something like this:

   public class GwtMockitoExtension implements BeforeEachCallback, AfterEachCallback {
   
     @Override
     public void beforeEach(ExtensionContext context) {
       // Invoke initMocks on the version of GwtMockito that was loaded via our custom classloader.
       // This is necessary to ensure that it uses the same set of classes as the unit test class,
       // which we loaded through the custom classloader above.
       GwtMockito.initMocks(context.getTestInstance().orElseThrow());
     }
   
     @Override
     public void afterEach(ExtensionContext context) {
       GwtMockito.tearDown();
     }
   }
   

   This allows us to run our GwtMockito tests with JUnit 5. The only thing we needed to change in the test themselves, was replacing the JUnit 4 Runners with the new GwtMockitoExtension.

   TL;DR: GwtMockito overwrites the ClassLoader in a custom Runner. JUnit 5 does not allow this, therefore a different way to overwrite the ClassLoader needs to be found. We used a custom LauncherInterceptor.