Property-Based Testing with fast-check for Edge Cases

This article explores how property-based testing, implemented through the JavaScript and TypeScript library fast-check, uncovers hidden edge-case bugs in complex web development algorithms. By shifting the testing paradigm from hardcoded examples to universal invariants, developers can automatically fuzz their code with hundreds of generated inputs. Below, we examine the mechanics of fast-check, how its input generation and shrinking algorithms work, and how it solves real-world algorithmic challenges in web applications.

The Problem with Example-Based Unit Tests

Traditional unit testing relies on specific inputs chosen by the developer. While effective for happy paths and known boundaries—such as passing zero, negative numbers, or empty strings—it inherently reflects the author's blind spots. Developers rarely think to test surrogate pairs, odd-length Unicode sequences, unbalanced JSON trees, or boundary-skating floating-point numbers.

In complex web algorithms—such as rich-text parsers, checkout price calculators, canvas renderers, and reactive state reconcilers—bugs often emerge from unexpected combinations of values rather than single bad inputs. Example-based tests struggle to expose these multidimensional edge cases.

How fast-check Works

fast-check is a property-based testing framework for JavaScript and TypeScript. Instead of checking that f(a) === b, it verifies that a general property holds true across an entire domain of generated inputs:

import fc from 'fast-check';

test('reversing a list twice returns original list', () => {
  fc.assert(
    fc.property(fc.array(fc.integer()), (arr) => {
      expect(reverse(reverse(arr))).toEqual(arr);
    })
  );
});

The framework operates on three primary components:

  1. Arbitraries (fc.arbitrary): Generators that define the shape and constraints of the test data (e.g., integers, objects, URLs, dates, or custom domain models).
  2. Properties (fc.property): Declarative rules that must remain true for any valid input produced by the arbitraries.
  3. Runner (fc.assert): The execution engine that runs the property hundreds of times with randomized, pseudo-stochastic inputs.

Uncovering Edge Cases with Arbitraries

fast-check ships with built-in arbitraries designed specifically to surface edge cases in web environments:

  • Strings and Text Processing: Built-in primitives such as fc.string(), fc.fullUnicodeString(), and fc.unicode() automatically inject zero-width spaces, RTL overrides, control characters, and surrogate pairs. This directly exposes crashes in custom text parsers, string truncators, and slug generators.
  • Structural Diversity: Composite generators such as fc.record() and fc.oneof() construct deeply nested, irregularly shaped JSON payloads. This stress-tests schema validators and state management reducers against deep recursion, prototype pollution properties, and sparse arrays.
  • Numbers and Formats: Primitives generate extreme values such as -0, NaN, Infinity, Number.MIN_VALUE, and floating-point boundaries that break client-side financial calculations or pagination indices.

The Power of Shrinking

Finding an edge case is only half the battle; debugging a failure generated from an arbitrary 5,000-character string or a deeply nested 20-level object is extremely difficult.

fast-check solves this through shrinking. When an assertion fails, fast-check intercepts the failure and systematically searches for smaller, simpler variations of the failing input that still trigger the failure:

  • If an array of 50 elements fails, it tries subsets (25, 12, 1) until it identifies the exact minimal array needed to reproduce the bug.
  • If a complex Unicode string crashes an algorithm, fast-check strips away unnecessary characters until only the problematic code point remains (e.g., reducing a long paragraph to just "\u0000" or a single unpaired surrogate).

This provides developers with the absolute smallest reproducible example directly in the test output.

Invariant Patterns for Web Development

To effectively apply fast-check to web algorithms, developers identify invariants rather than exact outputs:

1. Round-Trip Serialization

Custom encoders and decoders (e.g., query string serializers, local storage adapters, or base64 helpers) must preserve identity:

fc.assert(
  fc.property(fc.record({ id: fc.uuid(), query: fc.string() }), (state) => {
    expect(deserialize(serialize(state))).toEqual(state);
  })
);

2. Idempotence

Operations like data normalization, sorting, or sanitization functions should produce the same output if executed more than once on that output:

fc.assert(
  fc.property(fc.string(), (rawHtml) => {
    const cleanOnce = sanitizeHtml(rawHtml);
    const cleanTwice = sanitizeHtml(cleanOnce);
    expect(cleanTwice).toEqual(cleanOnce);
  })
);

3. Metamorphic Properties

When testing search, filtering, or sorting algorithms, applying a stricter filter to a dataset should always return a subset of the original results:

fc.assert(
  fc.property(fc.array(fc.record({ age: fc.nat() })), fc.nat(), (users, threshold) => {
    const broad = filterUsers(users, threshold);
    const strict = filterUsers(users, threshold + 10);
    expect(broad.length).toBeGreaterThanOrEqual(strict.length);
  })
);

Summary

fast-check bridges the gap between traditional unit testing and automated fuzzing. By generating diverse, hostile inputs and automatically reducing failures to minimal reproductions, it systematically uncovers edge cases—such as encoding traps, numerical anomalies, and structural edge cases—that manual test suites consistently overlook.