The GienTech Wealth Connect Runbook

What this target is

GienTech Wealth Connect is the second build of the same bank-and-insurer: the customer, the four accounts, the three policies, the payees, the claims and every business rule are identical to the Angular build. What changed is everything a test actually touches — the framework, the markup, the widgets and the naming of the hooks automation holds on to.

It was built to a training specification: a React app that mimics the structure, styling conventions and, most importantly, the data-testid conventions of an internal bank admin portal, so that trainees practise locators and flows against a realistic DOM before they meet the real one. Everything in it is a mock — no back end, no real credentials, no real customer data.

Running it

The application lives at apps/connect-for-bank inside the automation repository, and ships as one self-contained HTML file. There are three ways to have it in front of you.

The live copy

https://connect-for-bank.129.126.127.126.sslip.io — always the committed bundle. Sign in with Global ID amara, password Passw0rd!.

The bundle the suite tests

npm test -- --project=connect-chromium     # the static server serves app/connect-for-bank.html on :8123
npm run serve:app                          # or just serve it, then open http://127.0.0.1:8123/connect-for-bank.html

app/connect-for-bank.html is committed, so the suite and the deploy need no build step. That file is the artefact under test — the same bytes that are deployed.

Working on the application

npm run app:connect:dev      # Vite dev server with hot reload on http://localhost:5173
npm run app:connect:build    # vite build → single file, copied to app/connect-for-bank.html

The build inlines every script, style and asset (vite-plugin-singlefile), including react-datepicker's stylesheet. The output is ~740 KB and needs nothing from the network.

The state model, and why it matters to a test

One consequence of the session flag being in sessionStorage: Playwright's storageState cannot carry it (it captures cookies and localStorage), so the suite signs in through the UI in every test. That costs about 300 ms and buys perfect isolation.

The screens

Fourteen screens, hash-routed so the single file works from any host or from disk. Every screen announces itself with an <h1> carrying bo-packages-h1-<page>; that is the element page objects wait on.

The id convention

Every meaningful element carries a data-testid of the form bo-packages-<role>-<context>-<element>. The prefix is kept verbatim from the portal this mimics because it looks like it comes from an internal component library — it does, there — and the point of training on it is to learn to read a pattern rather than memorise strings.

One helper on each side

// The application — src/testid.js. Every id in the app goes through this.
export const tid = (...parts) =>
  ['bo-packages', ...parts.filter((p) => p !== undefined && p !== null && p !== '')].join('-');

<tr data-testid={tid('row-transaction', txn.id)}>            // bo-packages-row-transaction-35
<Button testid={['button-view-transaction', txn.id]}>      // bo-packages-button-view-transaction-35

// The suite — ConnectBasePage. Specs never type the prefix.
protected bo(...parts: (string | number)[]): Locator {
  return this.page.getByTestId(['bo-packages', ...parts].join('-'));
}

Three rules the ids keep

1. Deterministic. No random suffixes, no timestamps. The same element has the same id on every run and on every machine.
2. Derived from data, not position. row-transaction-35 stays with transaction 35 after a sort, a filter or a new row above it. row-3 would not.
3. Roles are literal. input- is an <input>, select- a <select>, button- a <button>, td- a table cell. A reader of the id knows what to expect before opening DevTools.

The exception: the login card

The login screen's ids are copied from the training specification verbatim rather than composed — bo-packages-form-provider-form-button-verify-login-button, bo-packages-div-bcp-login-header-welcome-message-2. They do not follow the three-part grammar, and some are duplicated on purpose (both field wrappers are bo-packages-div-is-required / bo-packages-div-label), because that is what the portal does. The page object spells them out and says so; Appendix A lists all twenty-two.

The field wrapper: a state machine in data attributes

Every form field is rendered by one component, InputField, whose bordered container carries three attributes. Tailwind's data-[…] variants read those attributes to paint the border, so the visible state and the DOM state are the same thing — an assertion on the attribute is an assertion on what the customer sees.

Reaching the wrapper

The wrapper's id is the same on every field (bo-packages-div-label), so it is found by what it contains:

fieldWrapper(control: Locator): Locator {
  return this.page.locator('[data-testid="bo-packages-div-label"]', { has: control });
}

get globalIdWrapper(): Locator { return this.fieldWrapper(this.globalIdInput); }

The transitions, as tests

// error: blur an empty required field
await loginPage.globalIdInput.focus();
await loginPage.globalIdInput.blur();
await expect(loginPage.globalIdWrapper).toHaveAttribute('data-error', 'true');

// failed: a refused submit marks BOTH wrappers
await loginPage.signIn('amara', 'WrongPassword!');
await expect(loginPage.globalIdWrapper).toHaveAttribute('data-variant', 'failed');
await expect(loginPage.passwordWrapper).toHaveAttribute('data-variant', 'failed');

// back to normal: typing
await loginPage.passwordInput.fill('retyping');
await expect(loginPage.passwordWrapper).toHaveAttribute('data-variant', 'normal');

// disabled: the lockout
await loginPage.failSignIn(3);
await expect(loginPage.globalIdWrapper).toHaveAttribute('data-disabled', 'true');
await expect(loginPage.globalIdInput).toBeDisabled();

// succeed: the payee form after a valid add
await payeesPage.addPayee(PayeeBuilder.valid().build());
await expect(payeesPage.nameWrapper).toHaveAttribute('data-variant', 'succeed');

The submit button's disabled attribute is driven by the same real state: it is disabled until both login fields are non-empty and re-disables when one is cleared. Assert the attribute, not a class name.

The widgets

Native selects

Every dropdown is a real <select> inside the field wrapper, with bo-packages-select-<base> on the element and bo-packages-option-<base>-<value> on each option. One call does everything the Material overlay driver needed six lines for:

await page.getByTestId('bo-packages-select-premium-from-account').selectOption('usd');
await page.getByTestId('bo-packages-select-claim-type').selectOption({ label: 'Day surgery' });

The claim-type select is dependent: its options change with the policy and reset to “Choose a type” when the policy changes. Select the policy first.

react-datepicker

Date fields are the genuine library — the same .react-datepicker__* DOM as the portal — wrapped in the field shell. Three facts govern every interaction:

• The popup is a portal. It renders into #datepicker-portal at the end of <body>, not beside the input. A locator scoped to the filter bar never finds a day cell.
• The format is dd/MM/yyyy. Typing 01/09/2026 and pressing Enter sets 1 September. Typing the American order sets January.
• Neighbouring months are rendered too, greyed. Selecting “1” without excluding .react-datepicker__day--outside-month can pick the wrong month.

// Both ways in, from src/pages/connect/components/react-datepicker.component.ts
await transactionsPage.typeFromDate(new Date(2026, 8, 1));   // fill + Enter — the fast default
await transactionsPage.pickFromDate(new Date(2026, 8, 1));   // open, navigate, click — covers the widget

The sticky-actions table

Every table sits in a .sticky-actions wrapper; the last column (Actions) is position: sticky; right: 0. Header cells carry bo-packages-th-<column>, rows bo-packages-row-<kind>-<id>. The contract worth asserting is the CSS, not the presence of a column:

await expect(accountsPage.actionsCell('sav')).toHaveCSS('position', 'sticky');

Modal and toasts

The transaction detail modal is bo-packages-modal-transaction-detail, fields …-modal-transaction-detail-value-<name>, closed by bo-packages-modal-button-close, Escape, or the backdrop. Toasts render into one fixed container, bo-packages-toast-container, as bo-packages-toast-<kind> with the text in …-toast-<kind>-message. They dismiss themselves after six seconds — assert promptly.

Buttons

Buttons are Flowbite React's, so the <button> carries group relative flex items-stretch justify-center p-0.5 … and the label sits in a nested <span>. The enabled: / disabled: variants switch with the attribute, not with a second class — toBeDisabled() is the right assertion.

The transactions page

The page the specification designed to exercise both libraries. Thirty-five deterministic rows, every account, newest first — and among same-day rows the highest id first, so the order is total and never flakes.

Facts the tests are built on

These live in src/data/connect-data.ts. They are stated, not computed, on purpose: they are the numbers the seed was designed to produce, and a test that fails because one changed is doing its job.

Ids on this page

The dashboard's “View” buttons deep-link here as /transactions?view=<id>, which opens the modal on arrival — a second entry point worth a test of its own.

Business rules, and where they surface

The rules and their wording are identical to the Angular build, so the suite's business-rules.ts is shared. What this table adds is where each rule shows itself in this DOM.

Two rules cannot be reached through this UI and are therefore not tested here: transferring an account to itself (the destination list excludes the source) and choosing a bank that is not on the list (the bank is a closed <select>; the test proves it by leaving the placeholder selected).

The suite

The base page

export abstract class ConnectBasePage {
  protected constructor(protected readonly page: Page, private readonly titleKey: string, private readonly route: string) {}

  protected bo(...parts: (string | number)[]): Locator {          // composes an id
    return this.page.getByTestId(['bo-packages', ...parts].join('-'));
  }
  get title(): Locator { return this.bo('h1', this.titleKey); }        // readiness
  async expectLoaded() { await expect(this.title).toBeVisible(); }
  fieldWrapper(control: Locator): Locator { /* Chapter 5 */ }
  protected select(base: string) { return this.bo('select', base); }
  protected input(base: string) { return this.bo('input', base); }
  protected errorBox(context: string) { return this.bo('div-error', context); }
}

Unlike the Angular base page, locators are not scoped to a screen root: the ids are globally unique by construction, and React unmounts the outgoing screen synchronously, so there is no outgoing DOM to match against.

Files

Running it

npm run test:connect                        # chromium, ~15 s
npm run test:connect:all                    # chromium + firefox + webkit, 264 runs, ~30 s
npx playwright test --project=connect-chromium tests/connect/transactions.spec.ts
npx playwright test --project=connect-chromium --grep "@smoke"
npx playwright test --project=connect-chromium --ui

# The same suite against the LIVE deployment — the bundle is identical, the transport is not.
CONNECT_APP_URL=https://connect-for-bank.129.126.127.126.sslip.io/ npm run test:connect
npm run test:connect:live                   # the same, as a script

CONNECT_APP_URL points the connect-* projects at any deployment of the file without touching the Angular projects or the local servers. Run it after every deploy: it is the difference between “the file passed on my machine” and “the site works”.

Tags: every test carries @connect; the build-gating subset carries @smoke. The three projects need no setup project — the session lives in sessionStorage, so each test signs in through the UI.

Writing a test, start to finish

Requirement: a duplicate payee account number is refused, the register is unchanged, and the form shows the failed state.

1. Page object. ConnectPayeesPage already has addPayee(), errorMessage, rows and nameWrapper. Nothing to add.
2. Rule. payeeRules.duplicateAccount exists in the shared file.
3. Data. PayeeBuilder.valid().withAccountNumber(payees.verifiedLandlord.account) — valid in every respect except the one under test.
4. Spec.

import { test, expect } from '@fixtures/connect-fixtures';
import { allPayees, payees } from '@data/test-data';
import { payeeRules } from '@data/business-rules';
import { PayeeBuilder } from '@data/builders/payee.builder';

test('refuses a duplicate account number and marks the form failed @connect', async ({ signedIn, payeesPage }) => {
  await signedIn.managePayees();
  await payeesPage.expectLoaded();

  await payeesPage.addPayee(PayeeBuilder.valid().withAccountNumber(payees.verifiedLandlord.account).build());

  await expect(payeesPage.errorMessage).toHaveText(payeeRules.duplicateAccount);
  await expect(payeesPage.nameWrapper).toHaveAttribute('data-variant', 'failed');
  await expect(payeesPage.rows).toHaveCount(allPayees.length);   // what must NOT have happened
});

Four checks before it is done: the title states a requirement; every literal is a fixture, a rule or a builder call; it asserts what happened and what must not have; and it would fail if the rule were deleted.

Manual test cases to automate

Fifty test cases covering every feature of the application, written the way a manual tester would execute them — preconditions, numbered steps, an expected result per step — and each ending with the ids it needs. The intended use: run one by hand first, then automate it, then compare with the suite's version where one exists.

Coverage by area: authentication 8 · dashboard 3 · accounts 3 · transactions 8 · transfer 6 · payees 3 · policies and premiums 6 · claims 6 · profile and notifications 2 · end-to-end journeys 5.

Authentication

Dashboard

Accounts

Transactions

Transfer

Payees

Policies and premiums

Claims

Profile and notifications

End-to-end journeys

Exercises

Ten exercises against this application, in rising order of difficulty. Each names the screen, the thing to prove, and the ids or techniques it needs. Solutions to most already exist in tests/connect — write yours first, then compare.

Build, deploy, roll back

Server layout

npm run deploy:connect:provision    # once — vhost + certificate
npm run app:connect:build && npm run deploy:connect   # every update: rebuild, scp, verify

Rolling back

git checkout <previous-commit> -- app/connect-for-bank.html
npm run deploy:connect

The bundle is committed, so a rollback is a checkout and a copy; no build is needed. Health is a curl -sI on the URL (200, text/html) and a browser check that /#/bcp/login renders the welcome card.

Test-id catalogue

Every id, by screen. <id> is the entity's own id (sav, pol3, p1, c2, a transaction number); <base> is a field's base name.

Shell (every signed-in screen)

Shared field wrapper (every form)

Login — verbatim from the specification

Dashboard

Accounts and account detail

Transfer

Payees

Policies, policy detail, premium

Claims

Profile and notifications

Mock data reference

From apps/connect-for-bank/src/mockData.js. Identical to the Angular seed except for the transaction ledger.

Banks offered: DBS · OCBC · UOB · Standard Chartered · Maybank · HSBC. Transaction facts are in Chapter 7. Reference numbers minted in a session are TFR-, PRM- or CLM- followed by six digits.

Commands

Companion to the GienTech Wealth Automation Runbook. Every id and every count in this book is taken from the application source and the suite it documents; if they disagree, the source is right and this book has a bug.