Askr
Reference

Testing Utilities

Use testing utilities with the current published Askr packages.

  • @askrjs/askr/testing0.0.59

How to use testing utilities

Mock the query or route boundary, drive public state transitions, and inspect invalidation or route warnings without replacing the application runtime.

  1. Import the published @askrjs/askr/testing entrypoint.
  2. Keep testing utilities configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
import { createInvalidationRecorder, matchRoute, mockQuery } from '@askrjs/askr/testing';

const projects = mockQuery({ data: [{ id: 'p1', name: 'Northstar' }] });
const invalidations = createInvalidationRecorder();

expect(matchRoute('/projects/p1', { routes: registry.routes })?.params.id).toBe('p1');
expect(invalidations.calls).toEqual([]);

Query mocks

@askrjs/askr/testing exports `mockQuery` (aliased as `queryState`) for constructing a `Query<T>` in any state your components might see: `mockQuery(data)` for fresh data, plus `.loading()`, `.error(err, previousData?)`, `.refreshing(data)`, `.stale(data, reason?)`, and `.pendingWrite(data)`. Each accepts an optional `refresh` callback via `MockQueryOptions` so you can assert refetch behavior without touching a real query registry.

Invalidation recorder

`createInvalidationRecorder()` returns an `InvalidationRecorder` that captures every cache invalidation call made during a test — each record is `{ prefix, markPendingWrite }`, and the recorder exposes the running list as `calls` and the deduped `prefixes` seen so far. Call `.clear()` between assertions or `.stop()` when you're done listening, so recorders don't leak across test cases.

Route matching

`matchRoute(path, options?)` runs a path through the router's matching logic without booting an app, returning a `RouteMatch` or `null`; pass either a `manifest` or an explicit `routes` array via `MatchRouteOptions` to test against a specific route set. It's the fastest way to assert that a given URL resolves to the route you expect, including param extraction, before wiring up any actual navigation.

Warnings

`getRouteWarnings(options?)` surfaces route-collision problems as `RoutePatternWarning[]` — each warning reports the `kind` (currently `'route-collision'`), the conflicting `path`, the specific `segment` that collides, and an optional `namespace` for MFE-style route grouping. Run it in a test against your real route manifest to catch ambiguous patterns before they show up as a mis-routed request in production.