Testing a Game with Node

A tiny assertion harness

Testing is the same for any project: assert that your code produces the expected result, and fail loudly if not. The game's tests use a tiny harness:

function assertEqual(actual, expected, message) {
  if (actual !== expected) {
    throw new Error(`FAIL: ${message}, expected ${expected}, got ${actual}`);
  }
  console.log(`ok: ${message}`);
}

function assertTrue(value, message) {
  if (!value) throw new Error(`FAIL: ${message}`);
  console.log(`ok: ${message}`);
}

Every test calls one of these. If it throws, the run stops and the failure prints. If not, ok: is logged. The whole suite is just a list of these calls:

assertEqual(clamp(15, 0, 10), 10, 'clamp caps at the max');
assertTrue(aabb(rectA, rectB), 'overlapping rects collide');
assertEqual(new Score().score, 0, 'score starts at 0');

This is all the framework you need. Real test libraries (Jest, Vitest) only add describe/it and mock functions on top of assertEqual. Under the hood, every test is this same actual !== expected check.

Testing the math helpers

The purest, most important things to test are the helper functions, no browser, no state. Test the ones the game ships:

import { clamp, lerp, rand, randInt, aabb } from './utils/math.js';

assertEqual(clamp(5, 0, 10), 5, 'value inside range stays');
assertEqual(clamp(-3, 0, 10), 0, 'below-range clamps to min');
assertEqual(clamp(20, 0, 10), 10, 'above-range clamps to max');

assertEqual(clamp(5) < 2, clamp(5) < 15, 'rand is within [min, max)');

assert(aabb({ x: 100, y: 100, w: 40, h: 56 }, { x: 120, y: 130, w: 22, h: 22 }), 'overlapping rects collide');
assert(!aabb({ x: 100, y: 100, w: 40, h: 56 }, { x: 500, y: 110, w: 20, h: 20 }), 'far-apart rects do not collide');

clamp is used everywhere (movement, difficulty) so getting it right protects the whole game. aabb is the collision backbone. If these two are tested, a huge fraction of bugs can't exist.

The key insight: test the pure functions first. They have no dependencies, so they're the fastest to verify and the most relied-upon.

Testing scoring and fairness

Now test behaviour, that the classes do what they should. The Score class:

const s = new Score();
assertEqual(s.score, 0, 'score starts at 0');
assertEqual(s.total, 0, 'coin count starts at 0');
s.addCoin();
s.addCoin();
assertEqual(s.score, 200, 'two coins = 200 points');
assertEqual(s.total, 2, 'two coins counted');

And the fairness rules that the game cares about, the same guards we tuned by hand:

import { DIFFICULTY } from './app1/js/config.js';

// Difficulty is monotonic and capped.
assert(DIFFICULTY.speedAt(1000) <= DIFFICULTY.speedAt(5000), 'speed never decreases with distance');
assert(DIFFICULTY.speedAt(1e9) <= 720, 'speed is capped at MAX_SPEED');
assert(DIFFICULTY.spacingAt(1e9) >= 210, 'spacing never below the jumpable floor');
assert(DIFFICULTY.hazardRateAt(1e9) <= 0.85, 'hazard rate capped at 0.85');

These tests aren't just checking numbers, they encode the design promise: "the game gets harder, but never unfair." A regression (say, someone bumping the speed cap to infinity) would break these immediately. That's the point of tests: they lock in the rules you decided.

The tests mirror the "fairness" comments in config.js. Every cap (Math.min/Math.max) has a corresponding test, so the fairness can't silently break.