Spots 
Fifth in a series on using @relax.js/core with a coding agent. The previous piece was about seeing errors in a test. This one is about getting the component into a state where there is something to see. Everything here is from @relax.js/core/testing. Why plain jsdom is not enough An agent that knows Web Components will write this and be puzzled:
connectedCallback only runs when the element is in a document. Created and never attached, it is inert, for reasons that have nothing to do with the component. And once attached, anything it awaits finishes a task later, so asserting right after attaching sees the element before its data arrived.
Two helpers cover this. mount() attaches to document.body and hands back unmount(), which is also how you test disconnectedCallback:
flush() waits for pending microtasks and the next macrotask, so work started by a lifecycle callback has landed. You will see it after every user action in the page tests below. Fake the server, not the component
The page loads its data through @relax.js/core/http. fakeServer() replaces the network underneath that module with canned responses and records every request:
Paths include the configured base URL and exclude the query string, because that is what a server sees. A request nothing was registered for gets a 404 whose body lists what is registered, and it is recorded like any other, so an unexpected call shows up in server.requests instead of hanging or reaching the network.
The seam is deliberate. Do not stub fetch globally, and do not mock the component's own load() method. The component under test is the real one, and the assertion covers both what it rendered and what it asked for: A function body is called with the request, which is how a PUT answers with what it was sent:
Note requestSubmit(), not submit(). The latter skips the submit event, and the FormValidator that owns the form never hears about it. When an agent picks the wrong one, the test says so: the PUT is missing from server.requests. The failure path is one more on() with a status: Registration order matters: the first match wins. That is why the PUT is registered per test and not in beforeEach.
The page above is reached with routing.navigate(), not mount(). The difference is everything a page depends on: loadRoute() runs with the route parameters before the element is added, the element lands inside <r-route-target>, and routeData is set. mountRouting() registers the routes and puts the targets in the document; its navigate() resolves with the rendered component once it is inside the target, after all of that. No flush() needed for the load itself.
It rejects the way navigate() throws in the application: no route matched, or a guard stopped it. When the component never appears within the timeout, the rejection lists the errors reported meanwhile, so a loadRoute() that threw is named instead of leaving you with an empty target. The routes it takes are the app's own:
Fifth in a series on using @relax.js/core with a coding agent.