Making sure it actually works

How do you know a game actually works — not just today, but after every change? You could play it by hand every time, but that's slow and you'd miss things. Instead, programmers write tests: little programs that check the real program automatically. This game has a clever setup that lets it play itself thousands of times.

Concept: a "test". A test is code that runs your program and checks it did the right thing — "start a run, drive to the end, confirm the player won." If a future change breaks something, a test fails and tells you immediately, instead of a player discovering it later.

The problem: tests are slow if they need a screen

Normally, testing a game means opening a browser, clicking buttons, and watching — slow and fiddly. This game sidesteps that with the idea from the very first chapters: the same file can run with no screen at all.

Remember HAS_DOM, the yes/no box for "is there a screen?" When there's no screen, all the drawing is skipped, but the actual rules still run. So a test can start a game, make choices, and drive to the finale — all in memory, in a fraction of a second, no browser required.

The trick that makes tests trustworthy: no surprises

There's one more problem. The game uses randomness — dice rolls for events, wear, luck. Random results would make tests unpredictable: pass one run, fail the next, for no real reason. The fix is a seed.

3909      setSeed: function (n) { rand = (n === null || n === undefined) ? Math.random : mulberry32(n); },

Concept: a "seed" (repeatable randomness). Computer randomness can be started from a chosen number called a seed. Same seed, same sequence of "random" results, every time. Tests use a fixed seed so a playthrough is identical on every run — which means if a test fails, it's because something genuinely broke, not because of bad luck.

What the tests actually check

With those two tricks — no screen, fixed dice — the game can test itself thoroughly and fast:

• Play entire tours start to finish and confirm they end sensibly.
• Check the rules: the economy, the perks, the Peak, saving and loading.
• Draw every single screen (as text) and make sure none come out blank or broken.

That last one is a favorite: it "renders" every screen without a browser and checks nothing is missing — catching the classic "I added a screen and forgot a piece" mistake. The whole suite runs in under a second, so the developers can run it constantly and catch problems the moment they appear.

The tests for this version

The newer parts have their own tests. They start a private copy of the server with saved archive data (so they never touch the internet), try every kind of request, and even play the real game in a hidden browser until it reaches the first parking lot. One test also checks this guide: every piece of code it quotes must still be findable in the running game.