Harness design - NexusTomorrow/server GitHub Wiki
The design for the test harness: the real server run in-process with headless clients that speak the client's protocol, and the scenarios that drive it. Step 3's first stage builds it with the pregame scenarios; the tick controls and the allocation gate come with the map side. Which tests run where, and what never leaves your machine, stay on Server core design. Roadmap says how far the build has got.
The idea
In short
A scenario starts the real host in-process, on free loopback ports, with a fresh database and a fake clock, and connects headless clients to it over real sockets. It sets things up through the command layer and asserts on what the clients receive, with expectations written from what the client needs.
Why
The checks that matter are the ones a real client would notice, and a scenario is the closest a test gets to one without the client: the same host, the same sockets and the same bytes. Driving it through the command layer means a scenario changes the server the way an admin would, never by reaching into an owner.
Decisions
Locked
The test harness runs the server in-process with headless clients speaking the real protocol. Scenarios drive the server through the command layer and assert on what the clients receive, with expectations written from what the client needs.
It runs the real host. The harness builds the same composition as the server (Host design), on free loopback ports, with a fresh database and fixture tables. Fixtures use made-up values, never rows from the client's tables.
A headless client's side of each message comes from the same declaration as the server's, so the two can't drift apart.
| Harness control | Does |
|---|---|
| Virtual clock | Owners tick on test time |
| Tick advance | n ticks, or until a condition or a timeout |
| Seeded randomness | Logged per test, so a failure replays |
| Scripted login | From the first handshake to in the world in one call |
| Setting overrides | Per test, through the settings registry |
Two gates fail a test outright: any steady-state allocation per map tick or per flush, and an owner that stops ticking.
The first scenarios
The pregame scenarios cover what a real client would trip over first:
- a game token works once, and an expired one is refused;
- a second login replaces the first;
- two accounts can't share a character name in any case;
- a message below
Fieldsis dropped, and the session carries on.
Tick advance and the allocation gate need a map, so they arrive with the map side.
Open
- Nothing in the design.
Rejected
None recorded yet.
Verification status
| Claim | Basis |
|---|---|
| That a scenario's expectations match the client | Written from the facts on Client protocol; a real login against the first stage is the cross-check |
Open questions
- The load test that puts hundreds of headless clients in one map is on Server core design.