Testing

Testing

WorldgenLib uses several checks because a compiling mod does not prove that the runtime seams, ordering, persistence, and server lifecycle are correct. The results below are the recorded development verification for version 0.1.0.

Recorded results

Check	Result
Release library build	0 warnings, 0 errors
ExampleRiver build	0 warnings, 0 errors
WorldgenLib.Tests	102 of 102 passed
IntegrationTests	14 of 14 passed
Debug parity suite	17 of 17 passed
Headless server scenarios	3 of 3 passed for each Vintage Story version in the 1.22.0 through 1.22.7 matrix
Versioned server matrix	24 of 24 lifecycle and startup-generation checks passed
Seed 42 server smoke run	Each version reached RunGame with no worldgen initialization error and shut down cleanly
Canonical WGLP parity matrix	8 of 8 versions passed vanilla×vanilla×WorldgenLib byte comparison
make agent-check	Passed in the development workspace

The aggregate development command is:

./scripts/run-parity.sh --server

The explicit project commands are:

dotnet build WorldgenLib/WorldgenLib.VintageStory.csproj
dotnet build WorldgenLib.ExampleRiver/WorldgenLib.ExampleRiver.csproj
dotnet test WorldgenLib.Tests/WorldgenLib.Tests.csproj -c Release --no-restore
dotnet test WorldgenLib.ParityTests/WorldgenLib.ParityTests.csproj -c Debug --no-restore

These commands belong to the development source tree. The public repository currently carries the documentation and release status, not the private development source or its reference assemblies.

What the tests cover

The unit and integration checks cover:

• ordered registration, freeze deadlines, tie ordering, and error isolation;
• context construction, moddata helpers, finalization boundaries, and global-Y block access;
• map stages, generator wrappers, padding, force requests, and region maps;
• landform indexes, threshold validation, reload behavior, and step remaps;
• BlockLayers structural validation and terminal adapters;
• conflict classification and lifecycle cleanup;
• sampler shape, cache invalidation, and allocation regression guards;
• parity harness mechanics and missing-artifact detection.
• canonical WGLP serialization, deterministic record ordering, full-stream comparison, and first-byte divergence diagnostics.

The headless server checks load the mod in a real server process, wait for the actual RunGame marker, exercise fixed startup scenarios, and verify clean shutdown. The parity scenario also captures map-region maps, Terrain-pass block and fluid IDs, and map-chunk heightmaps before accepting the output.

What the tests do not prove

The current suite does not prove all of the following:

• a real migrated Rivers-Mod, VSRiverGen, Watersheds, or Terra Prety build;
• strict additive composition with every foreign Harmony or middleware patch;
• numeric terrain-sampler equivalence with Watersheds' historical fork;
• the exact block-level effect of the BlockLayers inline seam on every Vintage Story binary from 1.22.0 through 1.22.7;
• byte-identical raw persisted saves, including entities, block entities, lighting, and process-sensitive late decoration state;
• a full native IMapRegion save and reload fixture;
• every native landform reload lifecycle;
• an in-game visual parity judgment for all terrain types.

The difference matters. A passing synthetic consumer demonstrates the API and host behavior. It does not turn the four-consumer seam matrix into four runtime migrations.

Adding a consumer regression

Use a fixed seed and keep the scenario small. Record the server version, mod versions, world settings, registered hooks, and expected output. Test both a clean pipeline and the composition with each provider that the consumer claims to support. Keep assertions on behavior, not on private implementation field names.