Test Run History

A log of notable test runs — what was run, the result, and what was learned.

---

2026-04-08 — testing-v2, first run

Scope: All specs (cypress/e2e/features/**/*.feature) — 2 feature files
Environment: Local Docker test stack (http://localhost:3001) against Nova Home Care Indiana org
Credentials: Master (superadmin@novavirtual.site), Admin (admin@novavirtual.site)
Runner: Cypress 13.15.1, Electron 118 (headless via make test-run)

Results

	Count
Total tests	8
✅ Passing	8
❌ Failing	0
Duration	~23 seconds

Specs

Feature file	Scenarios	Result
01_login/login.feature	4	✅ All passing
02_dashboard/dashboard.feature	4	✅ All passing

Notes

• First successful run of testing-v2 suite end-to-end
• Test stack started and torn down automatically via make test-run
• inotify watcher limit (fs.inotify.max_user_watches=524288) must be set on the host — two concurrent Vite dev servers exhaust the default limit
• make test-seed requires createsuperuser to run before loaddata — fixtures reference users_user.id=1

---

2026-04-02 — Login suite, first run

Scope: cypress/e2e/features/Login/**/*.feature (21 specs)
Environment: Local (http://localhost:3000) against Nova Health First, Inc org
Credentials: Superuser (superadmin@novavirtual.site)
Runner: Cypress 13.17.0, Electron 118 (headless)

Results

	Count
Total tests	21
✅ Passing	18
❌ Failing	3
Duration	~3 min

Passing (18)

All UI validation tests passed — field existence, required field errors, validation messages, password visibility toggle, forgot password button, wrong credential error toasts.

Failing (3)

Feature file	Scenario	Root cause
log_in_21.feature	User enters portal after correct login	Brittle Chakra selector
log_in_24.feature	Login successful	Brittle Chakra selector
login.feature	Login successful	Brittle Chakra selector

All three fail on the same assertion:

AssertionError: Timed out retrying after 4000ms:
Expected to find element: `p.chakra-text.css-6q9ebm`, but never found it.

css-6q9ebm is a generated Chakra UI class that changed since the tests were written. The login itself likely succeeds — the failure is in the post-login role assertion. See To Review for the fix plan.

How to re-run

docker compose run --rm cypress sh -c "npm install && cypress run --spec 'cypress/e2e/features/Login/**/*.feature'"

Reports are served at http://localhost:8090 via:

docker compose up reports

---

2026-04-03 to 2026-04-07 — DA-63: Full CNA application form + approval flow (investigation and closure)

Scope: cypress/e2e/features/Application_form_and_approved/applications_full_process_approved_Certified Nurse Assistant.featureEnvironment: Local Docker (http://localhost:3000) against Nova Home Care org Runner: Cypress 13.15.1, Electron (headless via Docker) Outcome: Ticket closed as superseded — see below

This run was the most diagnostically valuable of the handover period. Attempting to fix the CNA spec uncovered five independent defects stacked on top of each other, plus a real backend bug that had been silently breaking the application form for all local environments.

Defects found and fixed (in order of discovery)

1. Date inputs rejected by Cypress

Symptom: cy.type() error — "Typing into a date input requires YYYY-MM-DD format"

Cause: All four date fields in the feature file passed dates as MM/DD/YYYY (01/01/2024). Cypress's native date input handling requires ISO format.

Fix: Changed all dates in the feature file to YYYY-MM-DD (2024-01-01).

---

2. Application form stuck on Step 1 — captcha token rejected before bypass

Symptom: Form never advanced past Step 1. POST to the application endpoint returned 400 {"captcha_token": ["This field may not be blank"]}.

Cause (backend bug): ReCaptchaProtectedSerializer declared captcha_token as CharField(allow_blank=False) — the DRF default. In local environments where VITE_RECAPTCHA_KEY is not set, the React app sends an empty string. DRF rejects the empty string at field-level validation before run_validators is called, so the MWE_TESTING bypass in _validate_captcha_token is never reached.

Fix (DA-67): Changed to allow_blank=True. Empty tokens now pass field validation, reach the bypass check, and are accepted when GOOGLE_CAPTCHA_V3_TOKEN=MWE_TESTING.

File: django-api/novahomecareapi/utils/serializers.py

This was the only production-relevant finding from the DA-63 investigation. It was extracted to DA-67 and merged separately.

---

3. SMS consent blocked Step 4 submission

Symptom: Step 4 (ApplicationStep) could not be submitted — Formik validation blocked it silently.

Cause: The Yup schema for ApplicationStep requires smsConsent: mixed().oneOf(['true']). The test never checked the SMS consent checkbox, so validation always failed.

Fix: Added smsConsentCheckbox().check({ force: true }) to the signDocument() method in the application form page object.

---

4. Signature was drawn then immediately cleared

Symptom: Step 4 submitted but the signature field failed validation — the canvas was empty.

Cause: canvaElementSign in the page object was targeting .css-18lxp4n, which resolved to the Clear button on the SignatureField component, not a "Save" button (the component has no save button). The step drew a valid signature then called canvaElementSign.click(), which erased it.

Fix: Removed canvaElementSign. Rewrote signDocument() to draw via mousedown → mousemove → mouseup events directly on the <canvas> element, then advance with btnNext.click().

---

5. Post-login role assertion failing — brittle Chakra selector

Symptom: AssertionError: Expected to find content: 'Administrator' within <p.chakra-text.css-6q9ebm>

Cause: css-6q9ebm is a Chakra UI build-time generated class. It had changed since the tests were written. This was the same class of defect identified in the 2026-04-02 login run.

Fix: Changed roleTitle selector from p.chakra-text.css-6q9ebm to cy.get('header'). The admin role display is rendered inside <Box as="header"> (the AppBar) — a stable semantic element.

---

What the investigation revealed about the suite as a whole

Every fix uncovered another failure. This pattern — compounding brittle selectors, missing test state, no shared step definitions, incorrect formats, wrong elements — indicated that the suite had not been run end-to-end since it was written. Patching individual specs was producing diminishing returns.

The decision was made to replace the suite entirely. See Why We Replaced the Testing Suite for the full rationale and what testing-v2 does differently.

---

2026-04-03 — Application form suite, first run

Scope: cypress/e2e/features/Application_form/**/*.feature
Environment: Local Docker (http://localhost:3000) against Nova Home Care Indiana org
Runner: Cypress 13.15.1, Electron (headless via Docker)

Results

All tests were failing before the root cause was diagnosed. Failures manifested as input[name='firstName'] not found — the application form page never loaded.

Root cause — URL concatenation bug

The step definition the user navigate to the application form was concatenating two env var values:

cy.visit(Cypress.env(enviroment) + Cypress.env(business));
// Cypress.env('dev')  → full login URL (http://localhost:3000/login/<token>)
// Cypress.env('application_form_novahomecare') → full apply URL (http://localhost:3000/apply-now/<token>)
// Result: "http://localhost:3000/login/<token>http://localhost:3000/apply-now/<token>"
// → invalid URL → React Router 404 wildcard → "Page not found"

Fix: changed to cy.visit(Cypress.env(business)) — the application_form_* env vars already contain full URLs, no prefix needed.

File: testing/apps/novahomecare/cypress/e2e/steps_definitions/Application_form/application_form_mandatory_all.js

Other networking findings

• network_mode: host is required on Linux so Cypress can reach localhost:3000 and the SPA can call localhost:8000
• Using Docker service names (portals:3000) fails because the SPA's API calls from the browser still target localhost:8000
• Confirmed: Django API returns correct org JSON from within the Cypress container before the fix

See Environments for full networking details.