Harness CI Integrates Playwright, Cucumber for Robust E2E Test Pipelines

Establishing a Two-Repo Architecture for Test Suites

Integrating end-to-end (E2E) automation into enterprise CI/CD pipelines demands a structured approach to reporting, execution control, and artifact management. This guide details the setup of a Node.js test suite leveraging Playwright and Cucumber.js within Harness CI, emphasizing a two-repository architecture for enhanced modularity and dependency management. This setup supports parallel execution and generates dashboard-ready reports.

The core architecture relies on two distinct repositories:

• Repository A (Application Automation Repo): This repository houses the application-specific test assets. It includes feature files written in Gherkin syntax, Page Object Model (POM) definitions for interacting with the application's UI, and the pipeline definitions themselves. This keeps test logic tightly coupled with the application it validates.
• Repository B (Shared Framework Repo): This repository acts as a central hub for reusable testing utilities. It contains core framework functionalities, custom assertion libraries, and base driver configurations. By consuming this repository as a pinned dependency (e.g., via npm or Yarn), teams ensure consistency across multiple automation projects and prevent code duplication.

This dual-repo strategy allows for independent development and testing of the framework components while maintaining a clear separation of concerns from the application's test cases. It simplifies dependency management, ensuring that the automation framework is versioned and updated deliberately.

Configuring Harness CI for Playwright and Cucumber.js

Onboarding E2E automation frameworks to Harness CI involves meticulous configuration of infrastructure, secrets, and pipeline definitions. A 10-step checklist provides a roadmap for seamless integration.

Step 1: Replace Infrastructure Placeholders

The initial step involves updating pipeline YAML definitions, such as those found in .harness/e2e-poc.yaml and .harness/e2e-regression-parallel.yaml, with your specific Harness environment values. These placeholders ensure the pipeline correctly connects to your Harness organization and infrastructure.

• ORG_ID: Your Harness Organization Identifier.
• PROJECT_ID: Your Harness Project Identifier.
• GIT_CONNECTOR: The name of the Harness Git Connector configured for accessing your GitHub Enterprise repository.
• APP_REPO_NAME: The target application repository in the format owner/repo.
• K8S_CONNECTOR: The Kubernetes connector designated for your build infrastructure, allowing Harness to provision build pods.
• K8S_NAMESPACE: The Kubernetes namespace where these build pods will execute.

Ensuring these placeholders are accurate is critical for the pipeline to provision build environments and access necessary code repositories.

Step 2: Configure Environment Secrets

Next, secure sensitive information by configuring environment secrets within Harness. This includes API keys, database credentials, and any other sensitive data required by your E2E tests. Harness provides a secure vault for managing these secrets, which can then be injected into your build environment as environment variables. This prevents hardcoding sensitive information directly into your pipeline definitions or test code, adhering to best security practices.

Step 3: Define Pipeline Stages

Harness CI pipelines are structured into stages, each representing a distinct phase of the CI/CD process. For an E2E test suite, typical stages include:

• Build Stage: This stage involves checking out the code from your repositories (both Application Automation and Shared Framework), installing dependencies using npm or Yarn, and potentially building any necessary artifacts.
• Test Execution Stage: This is where Playwright and Cucumber.js are invoked. You will define commands to run your Cucumber tests, leveraging Playwright for browser automation. This stage should be configured to use the appropriate Harness infrastructure (e.g., Kubernetes connector) to spin up ephemeral build agents.
• Reporting Stage: After test execution, this stage focuses on collecting and publishing test reports. For Playwright and Cucumber.js, this typically involves generating reports in formats like Allure or JUnit. Harness can then ingest these reports to provide detailed test results and analytics within its UI.

Step 4: Configure Parallel Execution

To accelerate test execution, Harness CI supports parallelization. For Playwright and Cucumber.js, this can be achieved in several ways:

• Cucumber Parallelization: Cucumber.js itself offers built-in parallel execution capabilities, often through plugins or by sharding feature files.
• Playwright Parallelization: Playwright can run tests in parallel across multiple browser contexts or even multiple machines, significantly reducing total execution time.
• Harness Pipeline Parallelism: Harness can be configured to run distinct stages or even steps within a stage in parallel. This is particularly useful if you have independent test suites or different environments to test against.

The key is to coordinate these parallelization strategies. For instance, you might shard your Cucumber feature files and then have each shard executed by a parallel Playwright worker on a Harness-provided build agent.