Playwright Logo

UI Automation with Playwright

Discover a modern, capable, and reliable framework for end-to-end testing. This site demonstrates key features and comparisons for our automation solution.

What is Playwright?

Developed by Microsoft, Playwright is an open-source framework designed to automate web browsers. It provides a single, unified API to control all modern browsers—Chromium (Chrome, Edge), WebKit (Safari), and Firefox. It's built to enable fast, capable, and reliable automation, making it perfect for UI testing.

Key Features

True Cross-Browser

Write one test and run it on Chromium, WebKit, and Firefox. No more browser-specific workarounds.

No More Flaky Tests

Playwright's Auto-Wait feature automatically waits for elements to be ready, eliminating manual waits and sleeps.

Powerful Tooling

Comes with Codegen to record tests, Inspector to debug, and Trace Viewer to see exactly what happened.

Full Network Control

Intercept, mock, and modify network traffic. Test edge cases, simulate poor connections, and stub API responses.

Built for Speed

Leverage Browser Contexts to run tests in parallel, fully isolated from each other, for maximum speed and efficiency.

Multi-Language Support

Use the language you're comfortable with: JavaScript, TypeScript, Java, Python, and .NET are all supported.

Framework Comparison

Feature Playwright Selenium Cypress
Architecture Event-driven, WebSocket protocol WebDriver protocol (HTTP) Runs in the same event loop
Auto-Waits Built-in, intelligent waiting Requires explicit waits Built-in, automatic waiting
Browser Support All modern engines (Chromium, Firefox, WebKit) Extensive (all major browsers) Chromium-based, Firefox
Parallel Execution Native support for test sharding Via testing frameworks Via Cypress Dashboard service
Multi-Tab/Origin Full native support Supported but can be complex Limited support

Framework Architecture

These patterns create a robust, maintainable, and collaborative automation framework, from individual test components to the complete ecosystem.

1

Using a BDD tool like Cucumber, define scenarios in plain-text Feature Files. This makes tests readable by everyone—developers, QAs, and business analysts.

Feature: User Login
  Scenario: Successful login
    Given the user is on the login page
    When the user enters "admin" and "password123"
    Then the user should see the dashboard
2

These Java methods link plain-text steps to code, orchestrating calls to your Page Objects. They separate the test's intent from its implementation.

@When("the user enters {string} and {string}")
public void user_enters_credentials(String user, String pass) {
    loginPage.login(user, pass);
}
3

This is where the core automation logic lives. Page Objects contain the locators and methods to interact with the UI, while a Playwright Factory class manages the browser lifecycle, ensuring resources are handled correctly.

4

This class acts as a bridge between TestNG and Cucumber. @CucumberOptions points to the feature and step definition files.

@CucumberOptions(features = "...", glue = "...")
public class ClientOnboardingTest 
    extends AbstractTestNGCucumberTests {
}
5

This is the true entry point. It tells TestNG which tests to run, in what order, and configures settings like parallel execution.

<suite name="Suite">
  <test name="Regression">
    <classes>
      <class name="runner.ClientOnboardingTest"/>
    </classes>
  </test>
</suite>

The Complete Ecosystem

These final components enable scalability, manageability, and true continuous testing. Hover over each card to learn more.

Configuration Management

Decouple tests from environments. Use external files to manage URLs and credentials, letting you run tests against QA, Staging, or Production without code changes.

Advanced Reporting

Integrate tools like Allure for rich reports with screenshots, videos, logs, and historical trends, making debugging faster for everyone.

Data-Driven Testing

Maximize coverage with less code. Use TestNG's @DataProvider to run a single test method with hundreds of data combinations from Excel or JSON files.

CI/CD Integration

Integrate with Jenkins or GitHub Actions to automatically run your test suite on every code commit, providing instant feedback.

Project Setup: pom.xml

The pom.xml file is the heart of the project, managing all dependencies and build configurations. Below is an interactive look at its key components.


<dependency>
    <groupId>com.microsoft.playwright</groupId>
    <artifactId>playwright</artifactId>
    <version>1.44.0</version>
</dependency>
<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.10.2</version>
</dependency>

<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-java</artifactId>
    <version>7.12.0</version>
</dependency>
<dependency>
    <groupId>tech.grasshopper</groupId>
    <artifactId>extentreports-cucumber7-adapter</artifactId>
    <version>1.14.0</version>
</dependency>

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>5.3.0</version>
</dependency>
<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>5.2.3</version>
</dependency>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.0.0-M5</version>
    <configuration>
        <suiteXmlFiles>
            <suiteXmlFile>
                RegressionTestSuite.xml
            </suiteXmlFile>
        </suiteXmlFiles>
    </configuration>
</plugin>
Core libraries for browser automation and test execution.
Tools for behavior-driven development and creating rich test reports.
Libraries for API test automation and handling data from files like Excel.
The Surefire plugin is used by Maven to find and run the tests.

Project Directory Structure

A well-organized structure is key to a maintainable framework. Here’s a look at how our project is laid out, separating concerns like page objects, step definitions, and feature files.

  • /Complywise-integration-testing
    • assets
    • Downloads
    • reports
    • src
      • main
        • java
          • managers
          • Models
          • pages
          • reports
          • utils
      • test
        • java
          • context
          • hooks
          • runner
          • teststeps
        • resources
          • features
          • properties
    • docker-compose.yml
    • Dockerfile
    • entrypoint.sh
    • pom.xml
    • RegressionTestSuite.xml

Dockerized Test Execution

Docker encapsulates the entire test environment—including the correct browser version, OS dependencies, and Java/Maven setup—into a portable image. This guarantees that tests run identically on any machine, eliminating "it works on my machine" issues and simplifying CI/CD integration.

# STAGE 1: Builder - Prepares dependencies and browser binary
FROM mcr.microsoft.com/playwright/java:v1.47.0-focal AS builder

USER root

# Install Maven
RUN apt-get update && apt-get install -y --no-install-recommends maven && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy pom.xml to leverage Docker cache
COPY pom.xml .

# Download project dependencies to a shared location
RUN mvn dependency:go-offline

# Download the Google Chrome browser binary
RUN mvn exec:java -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="install chrome"


# STAGE 2: Final Image - Assembles the optimized runtime environment
FROM mcr.microsoft.com/playwright/java:v1.47.0-focal

USER root

# Install only runtime tools
RUN apt-get update && apt-get install -y --no-install-recommends maven xvfb && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy pom.xml first, so Maven has a project context
COPY pom.xml .

# Install ONLY the system-level OS dependencies required by Chrome
RUN mvn exec:java -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="install-deps chrome"

# Set up the virtual display environment
ENV DISPLAY=:99
RUN mkdir -p /tmp/.X11-unix && chmod 1777 /tmp/.X11-unix

# Copy pre-downloaded assets from the builder stage
COPY --from=builder /root/.m2 /root/.m2
COPY --from=builder /opt/google/chrome /opt/google/chrome

# Copy your project source and the entrypoint script
COPY . .
COPY entrypoint.sh .
RUN chmod +x entrypoint.sh

# Set default environment variables
ENV TEST_ENV=demo

# Set the entrypoint to run the test script
CMD ["./entrypoint.sh"]
services:
  playwright-tests:
    build: .
    volumes:
      - ./reports:/app/reports
      - ./target:/app/target
      - ./src/test/resources/properties:/app/src/test/resources/properties
    container_name: complywise-e2e-tests
#!/bin/bash

echo '==========================================='
echo 'Starting virtual display (Xvfb)...'
# Start Xvfb for headless browser execution inside the container.
Xvfb :99 -screen 0 1280x1024x24 &
sleep 2

echo 'Configuring E2E Tests...'

# Determine which environment properties file to use.
if [ -f src/test/resources/properties/env.properties ]; then
    FINAL_TEST_ENV=$(grep -E '^env=' src/test/resources/properties/env.properties | cut -d'=' -f2 | tr -d '[:space:]')
    echo "Using environment from env.properties: ${FINAL_TEST_ENV}"
else
    FINAL_TEST_ENV=${TEST_ENV:-demo}
    echo "Using environment from Docker variable: ${FINAL_TEST_ENV} (env.properties not found)"
fi

echo '==========================================='

# Run the tests, passing the environment name to Maven.
echo "Running Maven tests for the '${FINAL_TEST_ENV}' environment..."
exec mvn test -Dsurefire.suiteXmlFiles=RegressionTestSuite.xml \
             -Dplaywright.headless=true \
             -Denv=${FINAL_TEST_ENV}

# Build the Docker image (add --no-cache to force a fresh build)

>

# Run the tests inside the container (add --build to rebuild first if needed)

>

Running Tests Locally

When developing locally, you can run tests directly with Maven without Docker. This is often faster for debugging a single test or feature.

# First, navigate to the project directory and compile

>

# Run test suite with headless mode disabled and a specific environment

>
Full command: mvn test -Dsurefire.suiteXmlFiles=RegressionTestSuite.xml -Denv=demo -Dplaywright.headless=false