Originally created by: kumaakh
Originally owned by: joiskash
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.
Tests should verify call order:
startInstance() called firstwaitForSsh() called after startprovisionAuth() called after SSH is readyprovisionVcsAuth() called after authCan use vi.mocked().mock.invocationCallOrder or sequence the mock resolutions to enforce order.
The logic works correctly in production (verified on real hardware), but the test doesn't protect against future regressions that break the ordering.
Code review Round 2 & 3 — finding persisted across both rounds.
File: tests/cloud-lifecycle-unit.test.ts
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.