Skip to content

Strategic rationale for the E2E tests automation framework choices

Ticket #195: Strategic rationale for the E2E automation framework
Type: Strategy / Automation / Technical Positioning
Affected Component: e2e/, e2e/playwright.config.ts, e2e/package.json, e2e/src/pages/, e2e/src/tests/, and the project's technical documentation

1. Context

The Augmented Financial Analyst project has two main goals. It is both a private stock-portfolio analysis application and a place to experiment with software-development automation using AI.

In that context, the choice of the E2E automated test framework and its language could not be driven only by short-term technical convenience. It also had to support three broader ambitions: product reliability, skill-building on tools valued in the Canadian job market, and the ability to grow the project over the long term.

2. Initial question

The reflection focused on two related decisions:

  • which framework should be prioritized for UI automation (Playwright, Selenium, or Cypress);
  • which language should structure the framework over time (TypeScript or an alternative closer to the Python backend).

The goal was not to pick the “trendy” tool, but the combination that best fit the reality of the project: a private Flask application, strong QA expectations, test-driven documentation, continuous automation, and active experimentation around AI.

3. Option analysis

3.1 — Why Playwright stands out over Selenium and Cypress

Selenium remains a historical reference, but it often requires a heavier and more verbose orchestration layer to reach a comparable level of stability. For a solo, evolving project focused on fast iteration, that added friction would bring little decisive benefit.

Cypress, on the other hand, is very convenient for local front-end workflows, but it is less aligned with a broader E2E strategy involving multi-browser validation, structured reporting, traceability, and long-term framework maturity.

Playwright therefore offered the best balance for this project:

  • native support for chromium, firefox, and webkit;
  • modern and more stable browser execution;
  • HTML reports and traces useful for QA work;
  • strong compatibility with a Page Object Model architecture;
  • natural integration into a CI/CD and quality-documentation workflow.

3.2 — Why the TypeScript vs Python debate remained valid

The backend, the data pipeline, the Pytest test suite, and much of the repository automation already rely on Python. In a maximum-simplicity mindset, it would therefore have been perfectly reasonable to use Playwright in Python as well in order to reduce technological fragmentation.

That option remains relevant for a purely personal project optimized only for learning speed and single-language coherence.

4. Final decision: Playwright + TypeScript

Despite Python's consistency advantage, the more strategic decision for this project was to keep Playwright + TypeScript for the E2E layer.

This choice is justified by several factors:

  • it strengthens modern skills that are directly valued on the job market;
  • it aligns the project with current UI automation and QA engineering practices;
  • it provides better long-term structure for pages, fixtures, configuration, and scenarios;
  • it complements the project's Python foundation rather than competing with it.

The split then becomes clear:

  • Python for the backend, data, ETL, AI, and business validation;
  • Playwright + TypeScript for UI automation, user journeys, and browser-side reliability.

This separation is not a dispersion of effort; it is a deliberate compromise between technical coherence, useful learning, and employability.

5. Why this matters for the project and for the industry

For the project, this decision provides a stable direction: building a real application while turning the repository into a credible experimentation ground for SDLC automation, AI usage, durable documentation, and software quality.

For the software industry, it reflects a deeper trend: tomorrow's systems will need to combine multiple layers of expertise — backend, data, quality, CI/CD, structured documentation, and assistive AI — instead of treating them as separate silos. This project exists precisely to explore that convergence in a concrete, versioned, and measurable way.

6. Planned framework implementation roadmap

Following this strategic decision, the Playwright framework rollout was structured into 7 tasks:

  • Task 1: technical foundations (Ticket #167);
  • Task 2: intelligent navigation and architecture audit (Ticket #168);
  • Task 3: environment hardening and credential protection (Ticket #169);
  • Task 4: test-data intelligence with Faker and DDT (Ticket #170);
  • Task 5: performance and robustness optimization through Storage State (Ticket #171);
  • Task 6: advanced API and visual testing;
  • Task 7: traceability, retry, and CI/CD implementation.

This roadmap turns the strategic rationale into a progressive, operational, and measurable delivery plan.

7. Conclusion

In light of the project's goals, Playwright appears to be the best choice for the E2E automated test framework, and TypeScript the strongest long-term strategic complement, despite Python's dominant presence elsewhere in the application.

If the objective had been immediate simplicity alone, Playwright in Python could have been preferred. But for a long-term project centered on advanced automation and the development of market-relevant skills, the Playwright + TypeScript combination remains the most coherent recommendation.