Repository navigation
Harness server
The harness's moving parts: the harness server and its overrides, the headless client, and the test database. The scenarios that use them are on Harness scenarios, and why the harness is built this way on Harness.
The harness server runs the real host in the test process with these overrides, any of which a scenario can change:
| Override | Value |
|---|---|
| The clock | A fake one, fixed at a known time, which a scenario advances |
| The ports | Three free loopback ports |
| The console | Off |
| The unknown-account secret | A random one |
| Creation options | A fixture list with made-up values: one offered, one disabled |
It runs commands as the actor harness, with every permission. On teardown it waits for every owner's queue to empty before it stops the host, and an owner that stalls fails the scenario that stalled it.
- A scripted login signs on, logs in and enters character select in one call.
- A world session lists, creates, deletes and selects characters, and waits for any message it expects.
- Its side of each message comes from the same declarations as the server's.
A fresh database is made for each scenario and dropped afterwards, from NEXUSTOMORROW_TEST_PG. Without it the scenarios skip; with NEXUSTOMORROW_TEST_PG_REQUIRED=1, as in CI, they fail instead. Running the tests has how to set it up.
- Free ports are unique within one test process, so two test applications can rarely pick the same just-freed port.
| Piece | Path |
|---|---|
| The harness server, headless client and world session | Tests/NexusTomorrow.Harness/ |
| Test databases and fakes shared by every test project | Tests/NexusTomorrow.Testing/ |