Is the use of if (result.success) instead of expect.assert(result.success) intentional in tests?

[ShionTerunaga]

I am currently learning about writing test code, especially how TypeScript narrowing works with Vitest assertions.

While reading Zod's tests, I found several cases using the following pattern:

const result = schema.safeParse(input);

expect(result.success).toBe(true);

if (result.success) {
  expect(result.data).toEqual(...);
}

I understand that expect(result.success).toBe(true) does not narrow the type of result, so the additional if statement is needed before accessing result.data.

I noticed that Vitest also exposes Chai's assert API through expect.assert, so I wondered whether the following approach had been considered:

const result = schema.safeParse(input);

expect.assert(result.success);

expect(result.data).toEqual(...);

Is the current use of if (result.success) intentional, for example to keep the tests consistent with typical safeParse usage?

Or is there another reason not to use expect.assert for narrowing?

I understand that the current tests work correctly, so this is not a bug report. I was simply curious whether this pattern is intentional.

[paulodearaujo]

Your proposed version is valid with the Vitest version used by Zod today. Zod currently declares vitest: ^4.1.5, and Vitest 4 documents expect.assert specifically for cases where a normal expect(...).to* assertion cannot narrow the type.

const result = schema.safeParse(input);

expect.assert(result.success);
expect(result.data).toEqual(...);

Both forms fail the test when success is false. In the existing form, expect(result.success).toBe(true) performs the runtime assertion and the following if exists only to make TypeScript narrow the union. expect.assert(result.success) performs both jobs in one statement. The Vitest example shows that exact narrowing behavior.

The code alone does not establish whether Zod's current pattern was an intentional style choice. There is no technical reason to avoid expect.assert on the current test stack, though; changing those cases would be test cleanup rather than a behavioral fix.

[amasen02]

The pattern in Zod's test suite is intentional, driven by two primary considerations:

---

1. The Jest → Vitest Heritage

Zod's test suite was originally authored in Jest before the codebase migrated to Vitest.

Jest does not provide expect.assert or assertions with TypeScript asserts condition signatures. Under Jest, expect(result.success).toBe(true) verifies runtime correctness, but TypeScript does not narrow the discriminated union. The subsequent if (result.success) block was the standard TypeScript idiom to narrow the union safely in Jest without throwing compiler errors.

When migrating test runners, test suites generally preserve existing test code to avoid mass-churn on stable tests.

---

2. Mirroring Userland safeParse Idioms

Zod's safeParse is typed as a classic discriminated union:

type SafeParseReturnType<Input, Output> =
  | { success: true; data: Output }
  | { success: false; error: ZodError<Input> };

In production application code, consumers do not use test-runner assertion functions; they use standard control flow:

const result = schema.safeParse(data);
if (result.success) {
  // result.data is available
} else {
  // result.error is available
}

Structuring tests around if (result.success) ensures the test files double as canonical, copy-pasteable usage examples of Zod's type narrowing across all supported TypeScript versions (from older 4.x versions through 5.x), without relying on runner-specific assertion typings.