type-checking-vs-testing
Understand the Relationship Between Type Checking and Unit Testing
Overview
Type checking and unit testing catch different kinds of errors. Type checking catches type mismatches at compile time. Unit testing catches logic errors and edge cases at runtime. They complement each other - types reduce the need for some tests, but can't replace tests for logic.
When to Use This Skill
- Deciding between types and tests
- Catching logic errors
- Testing edge cases
- Building test suites
- Validating assumptions
The Iron Rule
Use types to catch type errors at compile time. Use tests to catch logic errors and edge cases at runtime. They complement each other.
Example
// Type checking catches:
function add(a: number, b: number): number {
return a + b;
}
add(1, '2'); // Compile error - types don't match
// Tests catch:
function divide(a: number, b: number): number {
return a / b; // Logic error: no check for division by zero
}
// Type system can't catch this - need tests:
test('divide by zero', () => {
expect(() => divide(1, 0)).toThrow();
});
Reference
- Effective TypeScript, 2nd Edition by Dan Vanderkam
- Item 77: Understand the Relationship Between Type Checking and Unit Testing
More from marius-townhouse/effective-typescript-skills
precise-any-variants
Use when forced to use any. Use when any is too broad. Use when function types need any.
86narrow-any-scope
Use when any is unavoidable. Use when working with untyped libraries. Use when silencing specific type errors.
35tsdoc-comments
Use when documenting public APIs. Use when writing library code. Use when using JSDoc-style comments. Use when generating documentation. Use when explaining complex types.
33exhaustiveness-checking
Use when handling tagged unions. Use when adding new cases to discriminated unions. Use when switch statements must cover all cases.
13code-gen-independent
Use when confused about types at runtime. Use when trying to use instanceof with interfaces. Use when type errors don't prevent JavaScript output.
12tsconfig-options
Use when setting up a TypeScript project. Use when confused by type checking behavior. Use when strict mode causes unexpected errors.
11