Type-Level Testing & API Design Patterns

30‑second interview answer

Type-level testing is about validating that your types behave as intended. In real codebases, you enforce constraints with satisfies, avoid unsafe as assertions, and design APIs that make invalid states impossible. For libraries, people use compile-time tests (like tsd or expectType) to prevent regressions.

Pattern 1: Prefer satisfies for configs

type Config = { mode: 'dev' | 'prod'; retry: number };
 
const config = {
  mode: 'prod',
  retry: 3,
} satisfies Config;

This validates shape while keeping literal inference.

Pattern 2: Avoid as unless you must

Bad:

const x = data as User; // can lie

Better:

• validate with Zod
• or narrow with a type guard

Pattern 3: “Make invalid states unrepresentable”

Example: a request that must be either success or error:

type Result<T> =
  | { ok: true; value: T }
  | { ok: false; error: string };

This prevents “value + error both set” bugs.

Pattern 4: Exhaustiveness

type Mode = 'light' | 'dark';
 
function assertNever(x: never): never {
  throw new Error('Unexpected: ' + x);
}
 
function f(mode: Mode) {
  switch (mode) {
    case 'light':
      return 1;
    case 'dark':
      return 2;
    default:
      return assertNever(mode);
  }
}

Type-level tests (concept)

In libraries, you can write compile-only tests:

• tsd (popular)
• dtslint (older)

Example idea:

// expectType<number>(fn())

Mini Q&A

Q1: Why prefer satisfies?

• it validates without losing literal types.

Q2: When is as OK?

• interop boundaries when runtime guarantees exist.

Q3: What’s a good type-level testing goal?

• prevent accidental breaking changes.

Summary checklist

• I prefer satisfies to annotations/as for configs.
• I design Result/union types for safer APIs.
• I use exhaustiveness checks.
• I know about tsd-style compile-time tests.