Skip to content

Task 2 of the automated tests framework - Intelligent navigation and architecture audit

Ticket #168: Intelligent navigation and architecture audit for the Playwright framework
Type: Automation / Quality / Test Architecture
Affected Component: e2e/src/pages/HomePage.ts, e2e/src/pages/LoginPage.ts, e2e/src/tests/loginTest.spec.ts, e2e/playwright.config.ts, e2e/package.json, e2e/eslint.config.mts

1. Context

After the initial Playwright foundation was established in task #167, the next step was to move beyond framework bootstrap and begin shaping the first business-oriented E2E architecture.

The goal was no longer just to have a working runner, but to model application navigation in a more maintainable way while auditing the real file layout and correcting structural inconsistencies discovered during setup.

2. Objective

This second step aimed to:

  • introduce an initial Page Object Model implementation for the login flow;
  • set up page chaining to improve readability and reuse in test scenarios;
  • create a first E2E test that reflects a user journey rather than a generic smoke check;
  • correct the e2e/ folder structure to better separate configuration from source code;
  • prepare the ground for the next layers: fixtures, environment variables, and CI hardening.

3. Delivered implementation

3.1 — Introducing Page Object Model chaining

The e2e/src/pages/LoginPage.ts file now encapsulates the main actions of the login page:

  • navigating to the login screen;
  • filling the username;
  • filling the password;
  • clicking the login button.

The key architectural addition in this iteration is the clickLoginButton(): Promise<HomePage> method, which directly returns a HomePage instance after the user action. This introduces a clear and reusable POM chaining approach.

3.2 — First abstraction of the home page

The e2e/src/pages/HomePage.ts file formalizes the landing page after authentication and centralizes an initial business-facing assertion through expectServiceTitleToBeVisible().

This encapsulation lays the groundwork for a cleaner testing strategy: assertions no longer live directly in the scenario, but in the object representing the actual page.

3.3 — First real-usage scenario

The e2e/src/tests/loginTest.spec.ts file now orchestrates a readable login flow from end to end:

  1. instantiate LoginPage;
  2. navigate to the login screen;
  3. fill credentials;
  4. retrieve HomePage via chaining;
  5. validate the landing screen.

This structure marks the transition from a purely technical demo test to an extensible business-oriented scenario, which is far better suited for the next stages of the framework.

3.4 — Architecture audit and configuration layout fix

A structure issue was identified during the work: several infrastructure files (package.json, package-lock.json, playwright.config.ts, eslint.config.mts, .gitignore) had remained under e2e/src/, even though they belong at the root of the e2e/ subproject.

The audit led to a cleaner layout:

  • framework configuration stays at the e2e/ root;
  • business test code stays under e2e/src/;
  • pages/ and tests/ keep their application-oriented role.

This correction immediately improves readability, maintainability, and alignment with standard Node/Playwright project conventions.

3.5 — Preparation for multi-browser execution and visual validation

The e2e/playwright.config.ts configuration keeps the framework ready for chromium, firefox, and webkit, with HTML report generation enabled.

A headed execution was launched with:

npx playwright test loginTest.spec.ts --headed

This validation exercised the new navigation chain and produced the expected Playwright artifacts while also revealing the last application-specific adjustments still needed (final selectors / credentials) before full industrialization.

4. Operational result

Task #168 is more than the addition of one extra test: it moves the framework to a more mature architectural stage.

At the end of this step, the project now has:

  • a first business page chain with LoginPage -> HomePage;
  • an E2E scenario much closer to real usage;
  • a healthier separation between configuration and source code;
  • a clean base for introducing fixtures, environment variables, and future hardening strategies.

5. Conclusion

This delivery represents a real maturity upgrade for the Playwright effort: the framework no longer rests only on initial installation, but on an intentional and extensible test architecture.

The groundwork is now in place for task 3, focused on securing environment variables, hardening sensitive credentials handling, and improving the reusability of automated scenarios.