samples-typescript icon indicating copy to clipboard operation
samples-typescript copied to clipboard

[Feature Request] Add sample: testing workflows containing startChild / executeChild / continueAsNew

Open NickolayCh opened this issue 2 years ago • 4 comments

It would be great to have an official solution from Temporal team for testing workflows that use startChild or executeChild, as long as continueAsNew.

NickolayCh avatar Jan 30 '23 20:01 NickolayCh

Hi Nickolay, thanks for the suggestion! How do you want to test the parent workflow? Are you wanting to mock the child workflow? What do you mean by "as long as continueAsNew"?

lorensr avatar Jan 30 '23 21:01 lorensr

Hey, I guess an example of some general use-case will be enough. We are currently running a separate worker with mocked child workflow before executing runUntil of the parent one, and I would like to understand if there's an easier or cleaner approach. And having such solution as a sample would be rather useful for the community too. As for continueAsNew - is there a good way to test it when using inside the workflow?

NickolayCh avatar Jan 30 '23 23:01 NickolayCh

if there's an easier or cleaner approach

If the parentFoo workflow starts childFoo, you can mock childFoo like this:

// test-parent.ts
export * from './parents'
export function childFoo() {
  // mock impl
}

// worker.ts
import { parentFoo } from './parents'

const worker = await Worker.create({
  workflowsPath: require.resolve(
    './test-parent',
  ),
});

const result = await worker.runUntil(
  testEnv.client.worklow.execute(parent, workflowOptions),
);

assert.equal(result, 42);

continueAsNew is not easily mockable, but you can check whether it continued as new by using a client to describe the new workflow execution. Alternatively, you can get the original workflow's history with fetchHistory and check the last event.

lorensr avatar Jan 30 '23 23:01 lorensr

I was just looking for a similar example. This looks useful for testing of our parent workflow. To clarify, we can mock the implementation of a child workflow by exporting a function with the same name correct?

The similar example I was looking for was mocking activities defined in a separate worker. Our workflow successfully calls activities both internal (defined within the same worker) and external (defined within a separate worker with a different queue name). Ideally we would mock the external activities but allow the internal activities to run so that we can assert on the results.

W0lfEagle avatar Sep 03 '23 17:09 W0lfEagle