3

May I ask what is the recommendation for Extension support in custom JUnit5 TestEngine?

Since extensions come from junit-jupiter-api (and not junit platform) is it a bad idea to try and support them in custom engines? (And is there some easy way to do that?)

I am writing a custom engine for JBehave tests and it might be really nice to easily reuse some extensions like TestcontainersExtension for Jupiter, but on the other hand I am wondering if what I am contemplating isn't a bad idea for some reason... Is there some recommendation about this? Or is there some easy way to provide extension support for custom Engines? (Ideally without reimplementing the same code from jupiter engine)

Pavel Jandejsek
  • 85
  • 7

1 Answers1

2

Having been there when the engine SPI and Jupiter extensions were initially conceived, we did not consider extensions a concept to be exported to other engines. The reason is the tight coupling that Jupiter’s extension points have with the details of a test‘s lifecycle. Just have a look at the many different extension points that only make sense if instance creation, set up, tear down, disabling, filtering, naming, stores and contexts work just like in Jupiter.

Will JBehave be able or willing to support all those fine-grained nuances and subtleties? If not, the you’ll run into the problem that some Jupiter extensions will work with JBehave as expected, some slightly differently, and others not at all. Another obvious drawback is the coupling to the full Jupiter API you’d have. That’s why I decided for jqwik.net to come with its own extension API.

That said, there are a few extension annotations that would make sense for many engines, eg Disabled, and should IMO be moved out of the Jupiter API into a common module. Another idea is to provide some kind of adapter for certain kinds of Jupiter extensions similar to how Jupiter can automatically use a subset of JUnit 4 rules.

johanneslink
  • 4,877
  • 1
  • 20
  • 37