Tests
Tests are tests/*.test.ts (and any src/**/*.test.ts), run by vitest in Node with no
browser. The whole suite takes a few seconds. A second, much smaller set drives the built
editor in a real browser; see Browser tests.
The suites open two sets of map files. tests/maps/ is committed: five small .scx and
.scm maps built by tests/support/testMaps.ts from the editor's own code, with nothing
of Blizzard's in them. Between them they cover the four file revisions, the three archive
compressions, an archive without a file list, triggers, a briefing, locations, a sound,
unit properties and unit settings. Every clone and CI runs the suites over these.
tests/maps.test.ts rebuilds each one and compares it with the committed file, so after
changing the code that makes them run npm run test:maps and commit the result. What
they do not have is terrain, which cannot be laid without a tileset.
fixtures/maps/ holds Blizzard's own maps, on a machine that has them. A suite that
holds for any map runs over both folders; the ones about terrain, doodads and what
StarEdit itself writes need the real maps, the extracted data in public/, or both.
Those use describe.skipIf(...) and skip silently when the files are absent, so a green
run on a fresh clone has not exercised them. CI has no game data and always skips them;
run them locally before touching a tileset decoder, the doodad code or the isometric
brush. fixtures/ and the generated public/ trees are gitignored, and nothing in them
may be committed.
Two suites are worth knowing about:
tests/plugin-network.test.tsfetches, transpiles and imports the real default plugins from GitHub. It is off unlessSCMJS_NETWORK_TESTS=1, and CI runs it in the web build and the release pre-flight, since opening the editor no longer walks that path.tests/docs.test.tschecks these documents: the split into site pages, every relative link, every picture, and that the plugin guide names only calls the API declares.