Testing untyped activity stub invocation

Community Support
,
1

Hi,
Is there any sample code to depict test cases for Untyped Activity Stub ?
I have a workflow(inside App A) which invokes untyped activity stub and the activity implementation resides in App B. So, trying to figure out about the test case logic for workflow so as to mock the untyped activity call invocation.

2

There are couple of ways, probably easiest is to register a specific worker that listens to the task queue as your activity in App B, for example in your test:

    @Before
    public void setUp() throws Exception {
        env = TestWorkflowEnvironment.newInstance();
        Worker workflowWorker = env.newWorker("t1");
        Worker activityWorker = env.newWorker("t2");

        workflowWorker.registerWorkflowImplementationTypes(MyWorkflowImpl.class);
        // register a mock here if you want 
        activityWorker.registerActivitiesImplementations(new MyActivityImpl());
        env.start();
    }
3

You do not have to use an untyped stub to invoke an activity on a different service (thats running the activity on a different task queue), you can do it typed as well. You would need the activity interface in your App A only, not the activity implementation which is in App B.

When using typed approach you can also think about not specifying your ActivityOptions inside your workflow code, but register per-activity options via WorkflowImplementationOptions and pass these when you register your workflow, for example:

WorkflowImplementationOptions workflowImplementationOptions =
                WorkflowImplementationOptions.newBuilder()
                        .setActivityOptions(
                                ImmutableMap.of(
                                        "MyActivityInAppB",
                                        ActivityOptions.newBuilder()
                                                .setScheduleToCloseTimeout(Duration.ofSeconds(5))
                                                .setTaskQueue("t2")
                                                .build()))
                        .build();

You can set the same WorkflowImplementationOptions in your test and then pass them to your test env worker that registers the workflow impl:

workflowWorker.registerWorkflowImplementationTypes(workflowImplementationOptions, MyWorkflowImpl.class);

This is better option than for example passing the activity task queue name as activity input.

4

As per my design, I do not have access to interface of activity in App A.Hence, using untyped activity stub.

5

With this approach, you mean to have a dummy activity implementation in App A just for test cases. Right?

6

As per my design, I do not have access to interface of activity in App A.Hence, using untyped activity stub.

You do not need the “actual” one. With untyped stub you need to know the activity Type and the activity return type and inputs anyways, so lets say that you are doing in your workflow code:

ActivityStub activity = Workflow.newUntypedActivityStub();
activity.execute("Run", String.class, input);

You could create an interface in App A based on that (match on activity type and return:

    @ActivityInterface
    public interface MyAppBActivity {
        String run(String input);
    }

and could invoke it with typed stub from App A using this interface.
(Note that by default in Java SDK, the activity type is the method name in your activity interface with first letter upper cased, thus you would call your interface method “run”, not “Run” as you would with untyped stub)
This would work cross-SDK with Temporal as well (for example invoking an activity written in Go from your Java client)

7

With this approach, you mean to have a dummy activity implementation in App A just for test cases. Right?

Yes, that would work, or mock it if you use typed approach ok too.