`medewerker-login.ts` becomes `keycloak-login.ts`: the three citizen specs each duplicated the same three-line password login, so a fix to the login path had to be made four times. They now call `loginBurger`, and both realms share `submitPassword`. No behaviour change — all 6 specs green against a live stack. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
22 lines
1.2 KiB
TypeScript
22 lines
1.2 KiB
TypeScript
import { expect, test } from '@playwright/test';
|
|
import { loginMedewerker } from './keycloak-login';
|
|
|
|
// S-15a walking skeleton: a beheerder logs in to the beheer portal (medewerker realm) and sees the
|
|
// read-only ZTC catalogus. The verify stack seeds and publishes the BIG-REGISTRATIE zaaktype (the
|
|
// same one verify-domain relies on), so it must appear in the catalogus. Runs against the shared
|
|
// verify stack, so it asserts on that stable seeded zaaktype rather than anything test-specific.
|
|
test('a beheerder sees the published zaaktypen in the catalogus', async ({ page }) => {
|
|
await page.goto('http://beheer/');
|
|
|
|
// The beheer portal redirects to the Keycloak medewerker realm login (same realm as behandel),
|
|
// which enforces MFA: password, then a TOTP code.
|
|
await loginMedewerker(page, 'bram-beheerder');
|
|
|
|
await expect(page.getByRole('heading', { name: /Catalogus/i })).toBeVisible();
|
|
|
|
// The seeded, published BIG zaaktype is shown by its business identificatie. Match the cell
|
|
// exactly (case-sensitive): getByText is case-insensitive, so it would also match the omschrijving
|
|
// cell "BIG-registratie" and trip strict mode.
|
|
await expect(page.getByRole('cell', { name: 'BIG-REGISTRATIE', exact: true })).toBeVisible();
|
|
});
|