Skip to content

Dashboard E2E validation

Ticket #233: Dashboard E2E validation on Chromium
Type: Automation / E2E / Quality / Documentation
Affected Component: e2e/src/pages/HomePage.ts, e2e/src/pages/DashboardPage.ts, e2e/src/tests/dashboardGlobal.spec.ts, e2e/src/tests/auth.setup.ts, e2e/package.json, docs/tests/dashboard.md, docs/fr/tests/dashboard.md, docs/features/chapter3.md, docs/fr/features/chapter3.md, How to/commandes_tests.txt

1. Context and objective

I added a dedicated E2E validation for the dashboard to cover a real user path after authentication. The objective was to secure a visible part of the application: reaching /dashboard, reading the key numeric blocks, validating business color cues, and confirming the presence of the main chart.

I also needed to make this suite easy to run again later by the operator, without manually rebuilding commands or interpreting ambiguous authentication failures.

2. Initial problems identified

Before this intervention, several weaknesses limited the operational robustness of the dashboard scope:

  • no dedicated Playwright test validated the real user path to the global dashboard;
  • the dashboard coverage documentation did not yet reflect the new complementary E2E validation;
  • operator commands did not provide a clear shortcut to run this suite;
  • when credentials were invalid, the authentication setup failed with an unclear URL timeout instead of an immediately actionable message.

3. Implemented solutions

The following actions were implemented:

  1. Dedicated Playwright dashboard suite

    • I created dashboardGlobal.spec.ts with 8 focused Chromium tests;
    • I covered navigation to /dashboard, indicator display formats, Top/Flop sections, Near Historic High/Low sections, and the presence of a single chart;
    • I kept the suite split by block so failures remain easy to diagnose.

  2. Dashboard logic centralized in a Page Object

    • I created DashboardPage.ts to group format, structure, and color validations;
    • I added a dedicated navigation path from HomePage.ts to the "Voir le Dashboard Global" button with fallback selectors;
    • I fixed the parsing of the "Threshold" rows by validating the normalized full row text, which is more robust than partial extraction from nested span elements.

  3. Improved authentication diagnostics

    • I hardened auth.setup.ts so invalid credentials now produce an explicit failure message;
    • I replaced a vague URL-timeout style failure with a direct signal on USER_ID/PASSWORD.

  4. Operational execution and documentation alignment

    • I added npm run test:dashboard and npm run test:dashboard:headed shortcuts in e2e/package.json;
    • I updated How to/commandes_tests.txt;
    • I synchronized the operational guide and the dashboard test coverage pages in EN/FR.

4. Validation and results

Validation confirmed that:

  • the authentication session can be regenerated cleanly once Windows secrets are corrected;
  • the new dashboard suite passes completely on Chromium;
  • the final observed result is 8 passed on dashboardGlobal.spec.ts;
  • launch commands are now shorter, stable, and documented;
  • the documentation better reflects the real dashboard coverage status.

5. Documentation and operational impact

I reviewed the documents impacted by this change:

  • chapter 3 of the operational guide for local E2E commands;
  • the dashboard test coverage pages to reflect pytest + Playwright complementarity;
  • the How to/commandes_tests.txt practical sheet for day-to-day usage.

The objective was to ensure that restarting this work later would not depend on memory or on manually reconstructing the context.

6. Conclusion

This intervention closes a concrete blind spot in the E2E framework: the global dashboard now has a user-oriented Chromium validation, clearer authentication diagnostics, and aligned operational documentation.

The scope intentionally left out of this delivery remains limited: multi-browser compatibility was not retained here, in line with the approved scope, and mobile display is still a separate item to handle independently.

7. Lessons learned

Summary analysis based on AI coach session artifacts

Available artifacts for this session (logs/ai_coach_active_session.json and logs/ai_coach_sessions/*.events.jsonl) currently expose only a session-start trace in events-only mode, with no detailed evidence about prompt quality, tool decision patterns, or token efficiency.

What worked well

  • execution remained outcome-driven, with immediate fixes until the Chromium suite reached full green;
  • technical traceability is strong on code/tests and final validation evidence;
  • EN/FR documentation synchronization was completed without scope drift.

AI coach evidence limitation observed

  • coaching evidence is currently insufficient for fine-grained session diagnostics because logs do not include detailed decision, prompt, or usage events.

Adjustment retained for upcoming sessions

  1. extend AI coach telemetry beyond SessionStart to include key prompts, major actions, and validation checkpoints;
  2. keep a short end-of-report summary that clearly separates verified findings from telemetry gaps.
  3. This adjustment task is planned in a new ticket #232 which will be dealt with in the future.