Resolving workflow interface(s) based on workflow implementation class

Hi Temporal team!

I was recently looking into building JUnit 5 extension for Temporal, similarly to the existing TestWorkflowRule for JUnit 4.

One of the cool features JUnit 5 provides is parameter resolvers - with it should be possible to automatically inject preconfigured workflow stubs into test class and methods. That requires the extension to have the list of workflow interfaces, however, it gets workflow implementation classes as input, so I’m looking for a way to resolve the workflow implementation class into workflow interface(s) it implements.

Looking through the SDK code, it seems that POJOWorkflowImplMetadata and POJOWorkflowMethodMetadata encapsulate all the logic required to do that, but they are package private.

How stable are those classes’ APIs? Would you consider opening them up?

Would you explain in more detail about “automatically inject preconfigured workflow stubs into test class and methods.”? I’m not sure what exact problem it solves that TestWorkflowEnvironment already doesn’t.

It should give a slight convenience by reducing some boilerplate. If we take some JUnit 4 test that uses TestWorkflowRule as an example

public class HelloWorkflowTest {

  @Rule
  public TestWorkflowRule testWorkflowRule =
      TestWorkflowRule.newBuilder()
          .setWorkflowTypes(HelloWorkflowImpl.class)
          // the rest of rule setup

  @Test
  public void verifyHelloWorkflow() {
    String taskQueue = testWorkflowRule.getTaskQueue();
    HelloWorkflow workflow =
        testWorkflowRule
            .getWorkflowClient()
            .newWorkflowStub(
                HelloWorkflow.class, WorkflowOptions.newBuilder().setTaskQueue(taskQueue).build());
    // test code goes here
  }
}

then with the JUnit 5 extension, the same test might look like

public class HelloWorkflowTest {

  @RegisterExtension
  public TestWorkflowExtension testWorkflowExtension =
      TestWorkflowExtension.newBuilder()
          .setWorkflowTypes(HelloWorkflowImpl.class)
          // the rest of extension setup

  @Test
  // extension injects HelloWorkflow stub, configured with proper task queue
  public void verifyHelloWorkflow(HelloWorkflow workflow) {
    // test code goes here
  }
}

@maxim Just to clarify: I’ve prototyped this JUnit 5 extension. However, in order for the extension to be able to go from the HelloWorkflowImpl class it gets as input to the HelloWorkflow interface it has to inject into the test method, I had to make some modifications to POJOWorkflowImplMetadata and POJOWorkflowMethodMetadata and make them public. I wonder if that might be something you could consider as a contribution, or should I take some other path?

I’m working on opening up POJOWorkflowImplMetadata. I will submit PR later today.

1 Like

Awesome, thank you!