Skip to content

Task 4 of the automated tests framework - Data intelligence

Ticket #170: Implementation - Data intelligence (Faker and DDT)
Type: Automation / Quality / Test Data
Affected Component: e2e/src/utils/dataGenerator.ts, e2e/src/data/contacts.json, e2e/src/tests/contactDataDriven.spec.ts

1. Context and objective

This intervention continues the Playwright framework rollout with a clear target: make E2E testing more robust and scalable without using production data.

It is a direct continuation of the previous stages: technical foundations, intelligent navigation and architecture audit, and environment hardening and credential protection.

Task 4 introduces a test-data intelligence workflow based on Faker and Data-Driven Testing (DDT), so I can cover many more scenarios while reducing long-term script maintenance.

2. Phase 1 - Synthetic data generation with Faker

To meet security and confidentiality constraints, the @faker-js/faker library was integrated into the E2E subproject.

A dedicated utility was implemented in dataGenerator.ts to:

  • define a minimal contact data model (firstName, lastName);
  • generate a configurable volume of random contacts;
  • export that dataset into a versionable static JSON file (contacts.json).

This provides realistic and diverse test inputs without exposing sensitive data, while keeping a stable fixture for local and CI runs.

3. Phase 2 - Move to a Data-Driven Testing strategy

The test scenario was refactored to read an external JSON file and iterate dynamically over each contact.

This avoids duplicating test code for each variation and makes scenario expansion very fast: new cases can be added in the dataset without changing test logic.

A key point was preserved: dynamic but explicit test titles, for example:

  • Test de creation pour le contact : Irma Bauch

When a run fails, the HTML report points directly to the failing data row, which accelerates troubleshooting.

4. Architecture incident and resolution

Observed incident

During an initial attempt to generate data directly inside the test file, execution failed with:

  • Test not found in the worker process. Make sure test title does not change.

Diagnosis

This exposed Playwright's two-step architecture:

  • test discovery phase;
  • worker execution phase.

Because data was being regenerated during file evaluation, test titles changed between discovery and execution, breaking worker matching.

Resolution applied

The fix followed a strict separation-of-responsibilities principle:

  • generate data in a dedicated utility script;
  • consume a pre-generated static JSON file in the test.

This ensures stable test titles and compatibility with Playwright parallel workers.

5. Validation and results

Validation confirmed a smooth execution of 9 tests:

  • 3 data rows (contacts);
  • 3 browser engines (chromium, webkit, firefox);
  • parallel execution without title-matching conflicts.

The environment-loading setup based on .env files remained stable throughout the full loop.

6. Conclusion

The framework now has an operational DDT foundation that can ingest a large number of data variations from external files without changing scenario business logic.

This chapter significantly reduces maintenance effort, improves failure-report readability, and prepares the E2E layer for larger-scale test expansion.