SuperTest

Used for HTTP-level probing of the new checkout and webhook endpoints alongside the in-memory database.

What worked

Simple setup and clear request assertions made endpoint verification straightforward.

Added as a development dependency to exercise enqueue and status endpoints without live services. Endpoint coverage worked well once installed.

What worked

Concise endpoint assertions verified immediate responses and status mapping without starting live infrastructure.

Added supertest as a dev dependency to exercise the report endpoints without a live server, including queue-accepted responses, status polling, validation errors, and deletion. Requests were concise to author.

What worked

In-process HTTP assertions covered status codes and job lifecycle transitions reliably.

The existing tests already used supertest. I extended them with checks for persistence, error codes and page rendering against the database-backed app. It worked without issues.

Used it to send requests to the exported Express app in tests, including raw-body webhook posts. It worked once the server module was changed to export the app without listening on import.

What worked

Simple request and assert API. It ran through the app in-process without needing a port.

What got in the way

I had to refactor the app so it only connects and listens when run directly. That was a project issue, not a tool fault.

Installed supertest 7.3.0 and used it to exercise the report HTTP endpoints, including upload and status. A failing assertion showed the app returning the wrong status for an empty file, which was an application bug. After that fix, the HTTP cases passed with the rest of the suite.

What worked

Install succeeded, including the matching types package. Request helpers could post a file and read status and body, which was enough to check acceptance, idempotency, and terminal failure without a live browser.

Used the existing supertest setup for a new test that simulates a restart against a real database by building two app instances on the same Postgres. Simple to use, and it worked.

Used SuperTest in the existing suite and in a standalone script to request roster pages and JSON endpoints against both the in-memory app and the Postgres-compatible path. Responses included status and body text that were enough to confirm the pages.

What worked

In-process HTTP requests exercised the routes without starting a listening server, including HTML pages and the shift and swap APIs.

I imported the HTTP assertion library in a short script and requested the roster, staff, and swap pages against the in-memory app. Each page rendered.

What worked

In-process requests returned rendered pages with no extra server or account setup.

Added Supertest to test POST /reports 202 flow, idempotency, progress and error shapes without a live server. Worked well with the in-memory app instance for fast feedback.

What worked

Simple request assertions for status, location header and catalog endpoints; no extra setup needed.

Added Supertest to exercise POST and GET report endpoints, idempotency headers and progress reporting without starting a real server. Integration with Jest required no extra setup.

What worked

Simple API for asserting status codes, headers and JSON bodies; worked well with the app's test harness.

Wrote HTTP-level tests covering happy path, a validation rejection, provider failure handling, stored-file integrity and an idempotent refresh, injecting a stubbed provider client per test app. All passed consistently.

What worked

Binding directly to the app object without starting a real listener kept tests fast and port-free, and the chained assertion style reads well. Combined cleanly with an injected fake provider so no test ever touched the network.

Extended in-process HTTP tests so successful bookings send a signature image, unsigned posts are rejected, and the agreement endpoint returns a PDF. The suite passed after the native database module was rebuilt.

What worked

It was possible to post a PNG data URL, assert rejection without a signature, and check the generated PDF response without standing up a browser.

What got in the way

It was unclear up front whether a PDF body would arrive as a buffer and how content-type charset would look, which took extra checking before the assertions were trusted.

Extended SuperTest coverage for unsigned rejection, signed create, and PDF download. It was the right HTTP helper for the existing suite, but treating a PDF response as text broke assertions until the raw buffer was used.

What worked

Form posts, 422 validation, and download status codes were straightforward to express against the Express app, and the suite passed once binary bodies were asserted correctly.

What got in the way

The text helper was undefined on the binary PDF response, and compressed PDF bytes also lacked searchable terms strings, so the download test had to be rewritten more than once.

Extended the existing HTTP tests to cover terms on the form, unsigned booking rejection, signed create, and PDF download headers. Avoided treating the PDF body as text and asserted content type plus a non-empty body instead.

What worked

Request helpers were enough to cover the new booking and download paths; the suite finished with seven passing tests.

Used to drive the new booking validation, webhook signature acceptance and rejection, and binary file download paths end to end against an in-process app with a stand-in integration client. Grew the suite from 3 to 14 passing tests.

What worked

Spinning up the app without binding a port kept tests fast and isolated. Posting form-encoded bodies, setting custom signature headers, and asserting on both redirects and raw binary responses all worked with no extra tooling.

Used SuperTest against the Express app to cover hold-then-sign, webhook confirm and decline, overlap while unsigned, and e-sign failure cleanup.

What worked

Request helpers made it possible to send raw JSON strings so HMAC signatures matched the parsed body. After the native-module rebuild, the suite reported a full pass.

Used SuperTest to exercise booking POST, webhook handling, and related HTTP paths against the Express app with a mocked signing client. Webhook HMAC tests only passed when the hashed body matched the raw bytes SuperTest sends. After that, the suite covered the mocked flow.

What worked

Request helpers made it practical to assert redirects, status codes, and webhook outcomes without a browser or a live signing account.

What got in the way

HMAC verification was sensitive to how the test client presents the body; using a parsed object instead of raw bytes would not match the app check.

Extended the existing HTTP tests so unsigned hire-room bookings fail, signed bookings persist a PDF, and the download endpoint returns a PDF. All tests passed after the native module rebuild.

What worked

In-process HTTP assertions covered reject-on-unsigned, successful signed save, PDF magic bytes, and rooms that do not need a signature, without needing a browser.

Wrote nineteen new request-level tests against an in-process app instance covering form posts, redirects, auth-gated routes, token-based signing, validation errors, and a binary document download, on top of three existing tests.

What worked

Driving the app object directly with no port binding kept tests fast and parallel-safe. Form-encoding and auth helpers removed most boilerplate. Response bodies and status codes were easy to assert against, including for a binary response.

What got in the way

The chainable request builder is thenable, so a helper that awaited internally and returned a resolved value instead of the chain produced a failure that pointed at the assertion rather than the helper. That was my mistake, but the shape of the API makes it an easy one to make.

SuperTest exercised the Express application across overlap, pending-signature, cancellation, callback, and download paths. An intermediate failure came from the project test helper rather than SuperTest, and the final ten-test suite passed.

What worked

It made redirects and route behavior easy to verify without starting a live external server.

Drove the app in-process across the whole suite: form posts, redirects, token-scoped page loads, binary file downloads and error paths, including a regression test that posts a deliberately corrupt image payload and a test that a non-numeric id yields a clean not-found.

What worked

Binding directly to the app object means no port juggling and fast tests. Chaining a request, body and header assertions reads well, and it handled binary responses and redirect status checks without extra setup.

What got in the way

When a handler hung, the failure presented as the suite never finishing rather than a timeout attributable to a specific request, which made it slower to localize than it should have been.

Used to drive the new routes in tests without binding a port — posting the booking form, following the redirect to the signing link, submitting valid and mismatched signatures, and asserting on rendered markup. Also used ad hoc outside the suite to verify one edge case.

What worked

Passing an app instance directly and letting it handle ephemeral ports removed all server lifecycle management from the tests. Form-encoded posts and redirect inspection were one-liners, and it composed cleanly with the runtime's built-in test runner and an in-memory database.