Skip to content

Task 3 of the automated tests framework - Environment hardening and credential protection

Ticket #169: Environment hardening and credential protection for the Playwright automation framework
Type: Automation / Security / E2E automated test framework Reliability
Affected Component: e2e/playwright.config.ts, e2e/package.json, e2e/src/config/.env, e2e/src/config/.env.qa, e2e/src/tests/loginTest.spec.ts, e2e/src/tests/encrypt.spec.ts, e2e/src/utils/cryptojsUtil.ts, e2e/src/utils/encryptEnvFile.ts

1. Context

After tasks #167 and #168, the Playwright framework already had a working technical base and a first login path. The next priority was to make that base usable under real operating conditions, without leaving readable credentials inside the scripts or multiplying manual setup steps for each environment.

A second issue also surfaced during execution: Playwright artifacts outside the e2e/ subproject were creating ambiguity and could trigger runner-loading conflicts. The work therefore had to secure both the secrets and the execution perimeter.

2. Objective

This third step aimed to:

  • separate test credentials cleanly from the source code;
  • allow simple environment switching through NODE_ENV;
  • add a protection layer for sensitive values through a runtime key (SALT);
  • stabilize Playwright usage around the e2e/ subproject only;
  • make test scripts easier to read for a non-technical stakeholder.

3. Delivered implementation

3.1 — Dynamic environment handling with dotenv

The file e2e/playwright.config.ts now loads the correct configuration file (.env or .env.qa) automatically based on the NODE_ENV value provided at runtime.

This decision avoids duplicating test scenarios by environment and prepares the framework for cleaner local, QA, and later CI/CD usage.

3.2 — Protection of test credentials

The files e2e/src/utils/cryptojsUtil.ts and e2e/src/utils/encryptEnvFile.ts introduce a simple encryption/decryption mechanism for sensitive values, driven by a SALT key injected at execution time.

The test e2e/src/tests/loginTest.spec.ts then consumes these decrypted values when the run starts. The goal was not to add unnecessary complexity, but to reduce credential exposure in day-to-day workflows and in the repository.

3.3 — Playwright perimeter cleanup

The investigation carried out during this task showed that a Playwright installation left at the repository root could conflict with the one in the e2e/ subproject, up to the point of causing a double-load runner error.

The decision was therefore made to centralize the entire Playwright setup inside e2e/ and remove competing artifacts outside that boundary. This cleanup clarifies ownership of the E2E subproject and makes execution more predictable.

3.4 — Reusable execution and QA readability

Reusable commands were added in e2e/package.json to make common runs easier to launch, especially the QA encryption test.

In parallel, the automated scripts in pages/, tests/, and utils/ were commented in intentionally simple, non-technical language. This reflects a practical operating choice: the framework must remain readable and maintainable for a QA-oriented user, not only for a developer.

4. Operational validation

The checks executed during this intervention confirmed that the new environment and security chain is working correctly:

  • successful execution from the e2e/ folder with npx playwright test src/tests/encrypt.spec.ts;
  • reusable command npm run test:encrypt:qa successfully validated;
  • observed result: 3 passed (1.9s), with effective encryption of .env.qa across the three configured browsers.

5. Operational outcome

Task #169 marks an important maturity step for the framework: the tests no longer depend on hardcoded values or on fragile local execution habits.

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

  • an E2E base that can switch environments without rewriting scenarios;
  • a simple protection mechanism for test credentials;
  • a cleaned and clearly scoped Playwright perimeter centered on e2e/;
  • a better QA operating experience through stable commands and embedded, readable guidance in the scripts.

The next logical step can now focus on richer business journeys and more advanced data-driven automation.