How to test with fsRoutes

[Toby222]

Is it possible to run tests on an app with fsRoutes? Every way I've tested ends with the app just not being able to access the routes

If no, ought there not be some kind of warning when using fsRoutes in a way that it doesn't have the necessary information?

[ryux1]

Yes. The key distinction is that .fsRoutes() does not crawl the routes/ directory at request time. It inserts routes that were already collected by Fresh's build cache. In a direct test such as new App().fsRoutes().handler(), no build cache has been attached, so the current implementation returns an empty list: app.ts#L339-L347.

For a unit test of one route, the simplest supported pattern is to import its handler and register it explicitly:

import { App } from "fresh";
import { handler as apiHandler } from "../routes/api/[name].tsx";

const handler = new App()
  .get("/api/:name", apiHandler.GET)
  .handler();

const response = await handler(
  new Request("http://localhost/api/joe"),
);

That is also the pattern in the current testing guide.

If the test specifically needs to verify filesystem discovery (layouts, middleware, route filenames, islands, and so on), it needs to go through a build so the route snapshot exists. With the current Vite setup, use createBuilder(), call await builder.buildApp(), and import the generated _fresh/server.js; the guide has a complete helper here. For the older Fresh Builder path, build an in-memory snapshot and apply it to the app before calling .handler(): builder testing example.

I agree that silently producing 404s when no build cache is attached is surprising. The behavior is explicit in the implementation, but it is easy to miss from the .fsRoutes() API docs. A warning or a focused documentation note would make this failure mode clearer. If your setup already runs through Vite and still cannot see the routes, please share the small test setup and vite.config.ts, because that would be a different issue.

[Toby222]

That requires the page export an explicit handler on the route that's meant to be tested, no?
And if you're wanting how the app reacts when using multiple routes, you end up effectively writing out the entire fsRoutes structure by hand anyways

I don't know how one would test with vite, I'm just using deno test and using app.handler() to make a handler to pass in the request

[Toby222]

Checked with the Builder pattern, too, and that just gives me incomprehensible errors about esbuild

Tried again with -A and that seems like it might work

It does not. It finds some routes but not all of them, seemingly it can't find the ones with [id] or similar parameters in the filename? I don't have many routes to test this behavior

[ryux1]

Right—the explicit handler pattern is only practical for a single-route unit test. For a multi-route integration test, the in-memory Builder snapshot is the better fit.

A file such as routes/users/[id].tsx is registered as a parameterized route, so the test request must use a concrete path such as /users/123, not /users/[id]. The other two easy gotchas are that Builder resolves routes/ from Deno.cwd() unless root is set, and the snapshot must be applied to the same app after .fsRoutes():

const builder = new Builder({ root: projectRoot });
const applySnapshot = await builder.build({ snapshot: "memory" });
const app = new App().fsRoutes();
applySnapshot(app);

const response = await app.handler()(
  new Request("http://localhost/users/123"),
);

If a concrete dynamic path still returns 404 with that setup, that is not expected. Please share the Fresh version, the small route tree, the request URL, and how projectRoot and the test command are set; that should be enough to reproduce whether discovery or matching is dropping the route.

[Toby222]

Okay I checked again, and it was in fact my bad
Builder works
The issue was that I return a throw a 404 HttpError for "user not found", but the notFound handler for my api routes ignored the error message and defaulted to "unknown API", which is the same as when that route is not registered, so it was actually just the test actually failing