Catalog Mock Helper

Configure HTTP mocks for a product search service so integration tests can run without hitting the real API. The helper should respond to dynamic product paths and query-driven searches when pointed at a configurable base URL.

Capabilities

Dynamic product paths

• When mocks are installed, a GET to {baseUrl}/products/<any-sku> returns HTTP 200 with JSON { "sku": "<sku>", "source": "mock" }, where <sku> echoes the requested segment without predefining the values. @test

Tag-filtered search queries

• A GET to {baseUrl}/search with query parameters q=<term> and repeated tags entries (e.g., tags=spring&tags=sale) returns HTTP 200 with JSON containing the received term, an array of the tags in their received order, and a stubbed results array keyed by those tags. The match must succeed regardless of query parameter ordering. @test

Encoded category queries

• A GET to {baseUrl}/search with category=home%2Fdecor returns HTTP 200 with JSON { "category": "home%2Fdecor", "results": ["encoded-category"] }; a request where the slash is unencoded should not use this mock. @test

Implementation

@generates

API

export interface CatalogMockHandle {
  /**
   * Lists any expected calls that have not yet been made.
   */
  pending(): string[];
  /**
   * Removes all installed mocks and restores normal network behavior.
   */
  restore(): void;
}

/**
 * Installs HTTP mocks for the product search service at the provided baseUrl.
 * Returns a handle to inspect outstanding expectations and remove the mocks.
 */
export function installCatalogMocks(baseUrl: string): CatalogMockHandle;

/**
 * Removes the mocks installed by installCatalogMocks and clears any pending expectations.
 */
export function resetCatalogMocks(): void;

Dependencies { .dependencies }

nock { .dependency }

Intercepts HTTP requests for the product search service and matches paths and queries.