bermudalamb
5c907fcf9a
Foundation only. No spec is converted in this commit, so the suite behaves exactly as before — the conversions follow in themed batches, each leaving the suite green. The suite had grown by copy-paste. Registering a customer was implemented nine times, as `register` in five files and `registerCustomer` in four more, each carrying its own re-explanation of the same bcrypt wait and the same "the header, not the URL, proves the session exists" reasoning. `uniqueEmail` was reinvented per file with a different prefix and a different encoding each time. Thirteen locators reached into antd's internals — `.ant-tabs-tab-active .ant-tabs-tab-btn`, `.ant-select-item-option[title=...]`, `.ant-col` — spread across seven files, so an antd upgrade breaks tests that have nothing to do with it. Page objects hold named locators and the actions that operate on them; assertions stay in the specs, so a test reads as its own statement of what it verifies. The exception is an action waiting for its own completion — registering waits for the account button, opening an admin tab waits for its panel — because that wait is the action's contract, and pushing it to callers would recreate the duplication being removed. Fixtures carry the setup rather than the specs. `customer` registers through the API rather than the form: nine specs drove the registration form purely to arrive at a signed-in session, so a broken form failed a hundred tests that were not about it, and each paid for a bcrypt round-trip through the UI. `page.request` shares the browser context's cookie jar, so the session belongs to `page`. The specs that are genuinely about registration drive the form properly through `authModal`. `adminApi` takes its base URL from the Playwright config. One spec built its own request context against a hardcoded http://localhost:5173, so changing the port in the config would have moved every test except that one. The inline pg.Client in password-reset.spec.ts moves to support/db.ts. The reasoning for reading the database directly is unchanged and still right — an endpoint that returns a reset token for an arbitrary address is account takeover if it is ever reachable, and an environment gate is a thin thing to stand between that and production — but it no longer sits in a spec where it can be copied into the next one wanting a shortcut. Its default port becomes 55500, the local stack's, rather than 55432: that is the integration suite's disposable Postgres, a different database with different credentials that the app under test is not connected to, and it is Hyper-V-reserved on at least one machine here, so the spec failed with a bare ECONNREFUSED naming a port nobody had chosen. tsconfig.test.json type-checks the tree and runs as part of `npm run build`. It is separate from tsconfig.json rather than widening its `include`, because scripts/check-sonar-tsconfig.js compares the two configs' include arrays, and pulling the Playwright suite into SonarQube's analysis program is a different decision from type-checking it. The whole existing suite type-checks clean on the first run. Lint now covers tests/ with `project` rather than `projectService` — the service resolves a file to the nearest tsconfig.json, which for tests/ is the one that excludes them, and every file then errors as not part of a project. no-floating-promises is an error here: Playwright's API is almost entirely promises, and a missing await on an assertion does not fail, it passes having asserted nothing. Four rule families are switched off for tests rather than left as warnings. Bringing these files in scope added 45, of which none were defects, and #60's argument is that a gate nobody reads is not a gate. There is no React in this directory, and the hooks rules fire on ordinary functions whose parameter is named `use` — which Playwright fixtures are, by its own API. Test credentials are the point of a test and the project's own rule is that they live only in test paths, which is here. Math.random builds unique fixture names so parallel workers do not collide, and a cryptographic generator would say something untrue about what the value is for. The count is back to the 30 that src carried before. Refs #137
70 lines
2.7 KiB
TypeScript
70 lines
2.7 KiB
TypeScript
import { Client } from 'pg';
|
|
|
|
/**
|
|
* Direct database access for the tests, for the one thing the API deliberately
|
|
* will not give them.
|
|
*
|
|
* The password-reset token is only ever delivered by email, which these tests
|
|
* cannot read. It is read from the database rather than through a helper
|
|
* endpoint because an endpoint that returns a reset token for an arbitrary
|
|
* address is account takeover for every customer if it is ever reachable, and
|
|
* an environment gate is a thin thing to stand between that and production.
|
|
* Doing it here keeps the capability entirely inside the test process.
|
|
*
|
|
* That reasoning is unchanged from when it lived inline in
|
|
* password-reset.spec.ts. What has changed is that it is no longer sitting in a
|
|
* spec where it can be copied into the next one that wants a shortcut.
|
|
*/
|
|
|
|
/**
|
|
* The default port is 55500, matching scripts/start-local.ps1.
|
|
*
|
|
* It used to be 55432, which is the integration suite's disposable Postgres —
|
|
* a different database, with different credentials, that the app under test is
|
|
* not connected to. Worse, 55432 is reserved by Hyper-V on at least one machine
|
|
* here, so the spec failed with a bare ECONNREFUSED naming a port nobody had
|
|
* chosen. TEST_PGPORT still overrides, for CI and for anyone running the stack
|
|
* somewhere else.
|
|
*/
|
|
function connectionSettings() {
|
|
return {
|
|
host: process.env.TEST_PGHOST || 'localhost',
|
|
port: parseInt(process.env.TEST_PGPORT || '55500', 10),
|
|
user: process.env.TEST_PGUSER || 'redefined_local',
|
|
password: process.env.TEST_PGPASSWORD || 'redefined_local',
|
|
database: process.env.TEST_PGDATABASE || 'redefined_local'
|
|
};
|
|
}
|
|
|
|
/** Opens a connection, runs the query, and closes it whatever happens. */
|
|
async function withClient<T>(run: (client: Client) => Promise<T>): Promise<T> {
|
|
const client = new Client(connectionSettings());
|
|
await client.connect();
|
|
try {
|
|
return await run(client);
|
|
} finally {
|
|
await client.end();
|
|
}
|
|
}
|
|
|
|
/**
|
|
* The most recent password-reset token issued to an address.
|
|
*
|
|
* Throws rather than returning null: every caller is about to build a URL from
|
|
* it, and a missing token means the request under test did not do what it said,
|
|
* which is worth failing loudly at the point it happened.
|
|
*/
|
|
export async function readPasswordResetToken(email: string): Promise<string> {
|
|
return withClient(async (client) => {
|
|
const { rows } = await client.query(
|
|
`SELECT t.token FROM customer_tokens t
|
|
JOIN customers c ON c.id = t.customer_id
|
|
WHERE c.email = $1 AND t.kind = 'password_reset'
|
|
ORDER BY t.created_at DESC LIMIT 1`,
|
|
[email]
|
|
);
|
|
if (!rows.length) throw new Error(`no password_reset token issued for ${email}`);
|
|
return rows[0].token as string;
|
|
});
|
|
}
|