UCD.js Docs

Test Utils

Architecture notes for @ucdjs/test-utils

@ucdjs/test-utils provides reusable mocks, fixtures, and matchers for package and app tests across the monorepo.

Role

  • Supplies mock store APIs and subdomain handlers for client and store tests.
  • Provides reusable backend fixtures and async helpers so tests do not rebuild plumbing each time.
  • Encodes project-specific testing patterns in one place.

Mental Model

The package organizes around three needs:

  • fake HTTP surfaces with MSW
  • fake filesystems/backends for storage tests
  • shared assertions and tiny async helpers

The most important entrypoint is mockStoreApi(), which stands up the canonical mocked UCD API.

Method Flows

mockStoreApi(config)

mockFetch()setupMockRoute()MOCK_ROUTESmockStoreApi()mockFetch()setupMockRoute()MOCK_ROUTESmockStoreApi()loop[each canonical route]opt[customResponses provided]TestmockStoreApi({ versions, files, responses })normalize baseUrl and defaultsiterate route definitionsrouteconfigure route responseregister GET/HEAD handlerregister additional handlersmocked API readyTest

Mocked request handling

before/after hooksconfigured mock filesmock handlerbefore/after hooksconfigured mock filesmock handlerConsumerrequest mocked endpointoptional before hook + latencyresolve version/path or default responsebody + metadataoptional after hookHttpResponse with headers/status/bodyConsumer

Store subdomain mocking

mock file treecatch-all subdomain handlermockStoreSubdomain()mock file treecatch-all subdomain handlermockStoreSubdomain()TestmockStoreSubdomain({ files })register /:wildcard* handlerGET https://ucd-store.../{version}/{path}resolve file or directory entrycontent or listing metadatafile text, directory JSON, HEAD metadata, or 404Test

Design Notes

  • The mock API tracks the real endpoint shape, including the manifest route compatibility layer.
  • Store-subdomain mocking exists because the HTTP backend talks to the hosted store directly, not only the API app.
  • Default files are included so tests can start from a realistic baseline without a lot of fixture setup.
  • The package is opinionated toward this monorepo’s testing style rather than being generic.

Testing Use

  • end-to-end client/store tests using realistic route mocks
  • backend feature tests using memory or read-only test backends
  • matcher setup for response and schema assertions
  • latency, error, and custom-response branches for HTTP consumers

On this page