How to use existing JUnit Jupiter @BeforeEach and @AfterEach in new engine?

[incident-recipient]

I'm making a new library on the jupiter platform. Each test method has a special annotation that generates many tests, but I want to leverage the existing lifecycles so I'm avoiding @TestFactory.

What I've done is make a new class descriptor that extends from ClassTestDescriptor. Unlike JUnit 5 the methods I annotate create many test cases.

Overall it's almost working exactly how I need it to: Each test runs and shows up properly nested in the IDE. The @BeforeAll and @AfterAll hooks are working fine too.

But for some reason @Disabled, @BeforeEach, and @AfterEach are not working.

What I'm doing is having each leaf node in the tree find the CustomClassTestDescriptor and invoke its methods:

  // See if we can find the MyCustomClassDescriptor parent which extends from TestclassDescriptor.
  // This will allow us to leverage the JUnit hooks for our tests
private Optional<MyCustomClassDescriptor> getCustomExecutionContext() {

    //Search through parents until we find the CustomClassDescriptor
    TestDescriptor nodeDescriptor = this;
    while (!(nodeDescriptor instanceof PdslJupiterClassDescriptor) && nodeDescriptor.getParent().isPresent()) {
      nodeDescriptor = nodeDescriptor.getParent().get();
    }
    if (nodeDescriptor instanceof MyCustomClassDescriptor) {
      return Optional.of((MyCustomClassDescriptor) nodeDescriptor);
    }
    return Optional.empty();
  }

  // Set up all hooks to kick off for this nested child test case
  @Override
  public JupiterEngineExecutionContext prepare(JupiterEngineExecutionContext context) {
    Optional<PdslJupiterClassDescriptor> classDescriptor = getPdslExecutionContext();
    if (classDescriptor.isPresent()) {
      return classDescriptor.get().prepare(context);
    }
    return context;
  }

// Run all before hooks
@Override
  public JupiterEngineExecutionContext before(JupiterEngineExecutionContext context) {
    Optional<PdslJupiterClassDescriptor> classDescriptor = getPdslExecutionContext();
    if (classDescriptor.isPresent()) {
      return classDescriptor.get().before(context);
    }
    return context;
  }
  
// Run all after hooks
  @Override
  public void after(JupiterEngineExecutionContext context) {
    Optional<PdslJupiterClassDescriptor> classDescriptor = getPdslExecutionContext();
    if (classDescriptor.isPresent()) {
       classDescriptor.get().after(context);
    }
  }

I've tried to navigate through the JUnit 5 ClassTestDescriptor to try to figure out why only some of the hooks are failing, see that they are associated with a registrar, but no indication on why they don't want to run.

Is there any advice on how I can get the remaining hooks to execute?

[sbrannen]

Officially speaking, the internals of the JUnit Jupiter TestEngine are not open for extension, and the JUnit team does not provide any support to achieve that.

However, perhaps someone in the community will assist you. Note that Stack Overflow might be a better option for such questions.

[incident-recipient]

Since this is an unsupported use case is there a way to make @testtemplate render the results hierarchically?

I got DynamicContainers to work with a @testfactory implementation but this still has the problem of not supporting @beforeeach.

I was sort of able to force the display to render the results I wanted using @nested, but in my use case this isn't practical as the framework is generating test cases dynamically (the manner in which the test cases render could change arbitrarily).

I see the class TestTemplateTestDescriptor which is definitely using the Hierarchical runner, but I haven't found any information indicating if I can modify it for a new use case.

Is there a supported mechanism within @junit5 that would allow generated tests to run hierarchically while still supporting standard JUnit5 annotations?

[incident-recipient]

I think the documentation for @TestTemplate may have the answer I need:

may also be used as a meta-annotation in order to
 * create a custom <em>composed annotation</em> that inherits the semantics
 * of {@code @TestTemplate}.

I think this means if I make my own annotation based off of @TestTemplate I can get all the JUnit5 features I care about provided I obey the contract. I'll go with that route and mark the issue closed if I'm successful. I'll leave the issue open until then so more informed people have a chance to correct my approach and others who may follow it if it's the wrong way to think about it.

[incident-recipient]

I found a solution.

Ultimately I made an interceptor for the @TestTemplate and did some hacking to inject my own TestDescriptor into the normal @TestTemplate descriptor.

Now all my hooks work, JUnit5 annotations are supported and the tests display properly.

I feel like I had to do some unclean things to integrate with JUnit5, but I guess the creators don't want me integrating directly with the framework based on the answer above. I didn't have a choice as my stakeholders demanded full parity. Hopefully someone else in my situation will be able to benefit if needed.