Menu

#7 F5 re-provisioning tests don't assert call order

open
nobody
None
2026-04-23
2026-03-24
Anonymous
No

Originally created by: kumaakh
Originally owned by: joiskash

Problem

tests/cloud-lifecycle-unit.test.ts — The F5 auth re-provisioning tests assert that mocks are called, but never assert ordering. The correct sequence is: start instance → wait for SSH → provision auth → provision VCS auth. If the order is wrong (e.g., auth provisioned before SSH is ready), it would silently fail in production but tests would still pass.

Expected behavior

Tests should verify call order:

  1. startInstance() called first
  2. waitForSsh() called after start
  3. provisionAuth() called after SSH is ready
  4. provisionVcsAuth() called after auth

Can use vi.mocked().mock.invocationCallOrder or sequence the mock resolutions to enforce order.

Priority: MEDIUM

The logic works correctly in production (verified on real hardware), but the test doesn't protect against future regressions that break the ordering.

Source

Code review Round 2 & 3 — finding persisted across both rounds.
File: tests/cloud-lifecycle-unit.test.ts

Related

Tickets: #70

Discussion

  • Anonymous

    Anonymous - 2026-03-24
     
  • Anonymous

    Anonymous - 2026-04-23

    Originally posted by: kumaakh

    Technical direction: Add call-order assertions to ests/cloud-lifecycle-unit.test.ts using Vitest's mock.invocationCallOrder. The fix is straightforward:

    ` ypescript
    // After the test assertion block, add:
    const startOrder = vi.mocked(cloudProvider.startInstance).mock.invocationCallOrder[0];
    const sshOrder = vi.mocked(waitForSsh).mock.invocationCallOrder[0];
    const authOrder = vi.mocked(provisionAuth).mock.invocationCallOrder[0];
    const vcsOrder = vi.mocked(provisionVcsAuth).mock.invocationCallOrder[0];

    expect(startOrder).toBeLessThan(sshOrder);
    expect(sshOrder).toBeLessThan(authOrder);
    expect(authOrder).toBeLessThan(vcsOrder);
    `

    This protects against future refactors that might reorder the provisioning sequence. Alternatively, sequence mock resolutions so each step only resolves after confirming the previous step completed — but invocationCallOrder is simpler and sufficient here.

     

Log in to post a comment.

MongoDB Logo MongoDB