Acceptance Test Suite

The acceptance suite checks example applications through their exported app objects rather than replacing those applications with test doubles. Each acceptance file requires an app from ../../examples/..., so the exercised behavior comes from the corresponding example source.

The files also require supertest, which supplies the request client used by the suite’s HTTP-facing tests. The excerpts show this setup consistently, but do not include the individual request calls or assertions from the acceptance files themselves.

Sources: test/acceptance/auth.js, test/acceptance/content-negotiation.js:3, test/acceptance/vhost.js, test/acceptance/auth.js:2

Core concepts

Example application

An example application is the app module loaded from a path under ../../examples/, making that example the system under test.

Sources: test/acceptance/auth.js, test/acceptance/multi-router.js

HTTP test client

The HTTP test client is supertest, imported by acceptance files so tests can exercise an app through HTTP-oriented test code.

Sources: test/acceptance/auth.js:2

Response assertion

A response assertion checks the returned status or body with chained .expect(...) calls; the shown test pattern accepts both a status and body, or checks them separately.

The acceptance setup has a simple hand-off: a test file requires both its example app and supertest. This diagram shows those two dependencies without assuming request or assertion calls that are not visible in the excerpts.

Sources: test/res.sendStatus.js:15-18, test/res.sendFile.js:357-362, test/acceptance/auth.js, test/acceptance/auth.js:2

How an acceptance test selects the application

The application under test is selected directly in each acceptance file by assigning require('../../examples/<name>') to app. That is why the suite boots an actual example module instead of a mocked application: the source dependency is the example path itself.

The mapping below identifies the example exercised by every acceptance file represented in the pack. The request column records whether that file imports supertest; the excerpts show that import for every listed file.

The source for an exercised app is therefore found by matching the test filename to the module path after ../../examples/; for example, mvc.js requires ../../examples/mvc, while web-service.js requires ../../examples/web-service.

Sources: test/acceptance/auth.js, test/acceptance/content-negotiation.js:3, test/acceptance/cookie-sessions.js:2, test/acceptance/cookies.js:2, test/acceptance/downloads.js:2, test/acceptance/ejs.js:3, test/acceptance/error-pages.js:2, test/acceptance/error.js:2, test/acceptance/markdown.js:2, test/acceptance/multi-router.js, test/acceptance/mvc.js:3, test/acceptance/params.js, test/acceptance/resource.js, test/acceptance/route-map.js:3, test/acceptance/route-separation.js:2, test/acceptance/vhost.js, test/acceptance/web-service.js:3, test/acceptance/auth.js:2

How responses are asserted

The visible assertion pattern is to call .expect(...) on the request chain. A single expectation can combine a numeric status and body, as shown by .expect(201, 'Created', done).

Separate expectations can instead check the status, a header, and the response body in sequence. The shown pattern checks 200, then Accept-Ranges: bytes, then 123456789, and finally ends the test with done.

This sequence diagram captures the proven setup order: the acceptance file requires the example app and then has the request client available. The excerpts do not expose the later request method, URL, or .expect(...) calls for the acceptance files, so those details are intentionally not drawn.

Some acceptance files also include small response-state helpers. auth.js extracts the first cookie from set-cookie, while cookie-sessions.js maps all cookie values, strips each value at the first semicolon, and joins the results with ; . The cookies.js test additionally imports shared support utilities from ../support/utils.

Sources: test/res.sendStatus.js:15-18, test/res.sendFile.js:357-362, test/acceptance/auth.js, test/acceptance/auth.js:2, test/acceptance/auth.js:4-6, test/acceptance/cookie-sessions.js:34-38, test/acceptance/cookies.js:4

How it connects

The acceptance suite connects the test harness to the example applications rather than directly constructing new applications inside each test file. The example modules are the hand-off point to the application behavior described in Examples: Getting Started, Examples: Views & Templating, Examples: Auth & Sessions, Examples: MVC & Route Organization, and Examples: Content Negotiation & Files.

The response expectations connect acceptance coverage to Express response behavior: status validation relates to res.status, body/status responses relate to res.sendStatus, and file-oriented checks relate to res.sendFile. Those implementation areas are explained further in Response: Sending Data and Response: Headers, Cookies & Redirects.

For the repository-wide placement of acceptance tests and their shared helpers, continue to Test Suite Structure.

Sources: test/acceptance/auth.js, test/acceptance/ejs.js:3, test/acceptance/mvc.js:3, test/acceptance/web-service.js:3, lib/response.js:65-77, lib/response.js:325-331, lib/response.js:334-361, test/acceptance/cookies.js:4

Key takeaways

• Each acceptance file requires a concrete module under ../../examples/, so its target is the real example app.
• The suite imports supertest as its HTTP test client.
• The visible response-assertion pattern uses chained .expect(...) calls for status, body, and headers.
• Match an acceptance filename with its ../../examples/<name> import to find the exercised source.

Sources: test/acceptance/auth.js, test/acceptance/web-service.js:3, test/acceptance/auth.js:2, test/res.sendStatus.js:15-18, test/res.sendFile.js:357-362, test/acceptance/mvc.js:3, test/acceptance/vhost.js