76d814e747
Unify declared instance HTTP API endpoints under typed middleware routing, including event streaming and PTY WebSocket connect handling.\n\nPreserve PTY connect compatibility by checking missing PTYs before parsing optional cursor and ticket query fields, with regression coverage.
1.7 KiB
1.7 KiB
Server Test Guide
Use these patterns for server and HttpApi middleware tests in this directory.
- Prefer focused middleware tests with tiny fake routes over full API route trees when testing routing, context, proxying, or middleware policy.
- Use
testEffect(...)withNodeHttpServer.layerTestfor the primary in-test server and make relativeHttpClientrequests against it. - Use tiny
HttpApiBuilderprobe groups that declare the typed middleware under test and expose context such asWorkspaceRouteContext,InstanceRef, orWorkspaceRef. - Declare middleware in the same order as production when testing interactions, for example
InstanceContextMiddlewarefollowed byWorkspaceRoutingMiddleware. - For secondary upstream servers, build Effect
NodeHttpServer.layer(...)into the current test scope withLayer.build(...)so the listener stays alive until the test scope exits. - Avoid
Bun.servewhen testing Effect HTTP middleware. Keep the test in the Effect HTTP stack unless the production path being tested is Bun-specific. - For WebSocket paths, use
Socket.makeWebSocket(...)from the test client and assert protocol forwarding or frame relay when relevant. - Use scoped test layers for flags, database reset, and other global mutable state. Restore flags and reset state in finalizers.
- Use
tmpdirScoped({ git: true })plusProject.use.fromDirectory(dir)for project-backed requests. - If a test needs persisted state without matching runtime state, keep direct database setup inside a narrowly named helper that explains that state.
- Add comments for non-obvious test topology, especially tests involving both the local test server and a fake upstream server.