Better @BeforeAll/@AfterAll experience for Kotlin

[translatenix]

I've written a small extension that makes @BeforeAll and @AfterAll more natural to use in Kotlin:

Old:

class MyTest {
  companion object {
    @BeforeAll
    @JvmStatic
    fun beforeAll() {...}
  }
}

New:

class MyTest {
  companion object {
    @BeforeAll
    fun beforeAll() {...}
  }
}

Is this something that could be contributed to JUnit itself? This would also give a better IDE experience than a third-party extension. (Currently IntelliJ complains that @BeforeAll is used without @JvmStatic and that beforeAll() is unused.)

[sbrannen]

As stated in the Test Instance Lifecycle section of the User Guide:

If you are authoring tests using the Kotlin programming language, you may also find it easier to implement non-static @BeforeAll and @AfterAll lifecycle methods as well as @MethodSource factory methods by switching to the "per-class" test instance lifecycle mode.

From what I understand, a lot of people using Kotlin prefer that approach.

Have you tried using @TestInstance(Lifecycle.PER_CLASS)?

[sbrannen]

I wish JUnit “just” treated Kotlin companion methods and fields the same as Java static methods and fields. They serve the same purpose. Could ReflectionUtils/ReflectionSupport be enhanced to do just that, if necessary behind a feature toggle? I don't know if it's technically possible, but I'd be willing to give it a try.

That's a good question, and I honestly don't know the answer... simply because I'm not an expert on Kotlin reflection.

However, if you'd like to investigate the options, feel free to do so!

If you put together a PR, that would give us something concrete to consider.

[translatenix]

Sounds good! Are Kotlin and the org.jetbrains.kotlin:kotlin-reflect library off-limits? (My current BeforeAll/AfterAll extension uses both and is very simple.)

[mpkorstanje]

I've had to consider a few very similar problems for Cucumber. For JUnit there are no nice solutions. I think your extension may already be close to optimal.

The problem with using pure Java to interface with Kotlin is that it depends on implementation details that may change. This is not a good long term solution.

This means using kotlin-reflect.

The problem with using kotlin-reflect is that is an optional dependency in Kotlin. So to work reliably it should be a dependency of the test framework using it.

This implies a dedicated module for Kotlin.

Finally the problem with companion methods is that they should be invoked on an instance of the companion. Unlike static methods in Java. This difference requires some encapsulation. And coincidentally, an extension provides this.

None of these are unsurmountable problems. But the other side of the scales only holds @JvmStatic.

[translatenix]

Fair points. On the other hand, if I stick to my own extension, I’ll also need to support TempDir, AutoClose, and other extensions coming my way. And the IntelliJ settings to avoid false positives cannot be shared via source control. (There’s a long-standing issue for it.) The annoyance with @JvmStatic is real—I’m pretty sure it’s why Kotlin devs apparently prefer per-class instantiation.

[translatenix]

I discovered another potential solution: a Kotlin compiler plugin that does the equivalent of annotating companion members of test classes with @JvmStatic.

[translatenix]

I looked into this in some detail today. Here's the summary:

1. I don't see a way to transparently expose Kotlin companion members through existing ReflectionSupport methods.
   It sort of works for companion properties (they are currently visible to extensions as private static fields) but not for companion functions. The primary reason is that companion functions are instance methods of the companion class.
   Hence returning them from ReflectionSupport.findMethods(testClass, ...) would confuse callers.
2. A way forward would be to introduce a KotlinReflectionSupport class written in pure Java.
   It could look as follows (TBD):

public class KotlinReflectionSupport {
  // (1)
  public static Optional<Object> findCompanionObject(Class<?> clazz) {...} 
  
  // (2)
  public static List<Method> findCompanionFunctions(
  Class<?> clazz, 
  Predicate<Method> predicate,
  HierarchyTraversalMode traversalMode) {...}
    
  // (3)
  public static List<Field> findCompanionProperties(
    Class<?> clazz, 
    Predicate<Field> predicate,
    HierarchyTraversalMode traversalMode) {...}
}

(1) and (2) would be used by JUnit itself (in one way or another) and
by third-party extensions that wish to support Kotlin companion functions.

(3) would be used by JUnit itself and by third-party extensions
that wish to distinguish Kotlin companion properties from Java private static fields.

Does this sound at all feasible? Otherwise I'll stop here.

The code I used in my investigation is available as a Gist.