Testing child workflow started in typescript-sdk

Community Support
,
1 
let testEnv

beforeAll(async () => {
  testEnv = await TestWorkflowEnvironment.createTimeSkipping()
})

afterAll(async () => {
  await testEnv?.teardown()
})

describe('test workflow', async () => {
  it('', async () => {
    const mockActivities = {
        ....
    }
    const worker = await Worker.create({
      connection: testEnv.nativeConnection,
      activities: mockActivities,
      workflowsPath: require.resolve('../'),
      taskQueue: '...',
    })

    const result = await worker.runUntil(
      testEnv.client.workflow.execute(mywf, {
        workflowId: 'wfid',
        taskQueue: 'queue',
        args: [...],
      }),
    )
    expect(result).toEqual({...})
  })
})

Workflow mywf executes child workflow. How do I test whether the child workflow was executed or not?

Thanks

2

Do you want to mock the child?
If so, you can export a different function with the child workflow’s name as shown here: TypeScript SDK developer's guide - Testing | Temporal Documentation.

Why do you need to check if the child was executed in the first place? One might argue that it’s an implementation detail.

If you are convinced that you need to check that the child was executed you have a few options, I’ll mention a few here:

  1. Get the workflow history and check that a StartChildWorkflowExecutionInitiated event is present or other child workflow related events.

  2. Inject a custom logger into the worker options default sinks and check in the emitted log messages that your workflow was executed.

  3. Implement your own interceptors and sinks to trace the execution.

  4. Use the SDK’s opentelemetry interceptors and inspect the emitted spans.

3

Thanks for the detailed reply.
I am looking for something like toHaveBeenCalledTimes(1) for the child workflow.

4

I understand, I’m just not sure why you want to test that.

5

just for the sake of coverage

6

Just want to point out another approach to mock child workflows. This is definitely not the easiest alternative (go for the other options suggested by bergundy if they make sense for your test cases), yet it makes it possible to use general mock testing semantics.

See details on this comment.