DEV Community: Rodrigo Cabral

Playwright with TypeScript: is AI really here to help? Playwright-cli?

Rodrigo Cabral — Wed, 25 Feb 2026 12:40:22 +0000

In this series, I build a test automation template using Playwright and TypeScript, and in this article, I put an AI tool to work alongside me in evolving the project.

Introduction

Continuing our journey to build a robust automation framework using Playwright with TypeScript, we’ve reached the point where we begin applying everything that was planned and structured in Part 1. So far, we’ve defined the project architecture, set up the development environment, and organized the folder structure so our tests remain clean, reusable, and easy to maintain.

In Part 2, we move into the hands-on phase of the framework: we’ll automate test flows on the PIM page and then cover scenarios related to JobTitle. As a complement, I’ll be using playwright-cli. Will AI really help me?

The full source code is available in the repository:

https://github.com/RodrigoOBC/PlaywrightTemplateTypeScript

Environment setup and project structure

For those who want to understand the full project setup and repository structure before we continue, I strongly recommend reading Part 1 of the series. In that article, I cover everything from environment setup to folder organization and the architectural principles behind the framework we’re using. The step-by-step explanation provides the context behind the decisions made and makes it much easier to follow the next chapters.

Playwright with TypeScript: Building an Automation Framework (Part 1)

What is Playwright CLI?

Modern code agents have been prioritizing CLI-based workflows exposed as skills rather than MCP, mainly for efficiency reasons. Command-line calls consume fewer tokens by avoiding the loading of large tool schemas and extensive accessibility trees into the model’s context. As a result, agents can execute actions through more direct and specific commands.

In practice, Playwright CLI is a set of skills that allows your preferred code agent, whether Copilot, Claude, Codex, or others. To run automated tests with Playwright through natural language requests. It loads this skill set and effectively becomes an automated testing agent.

Subtle change in the architecture

While creating the tests for the PIM page, I noticed that the system is organized into tabs, and within each tab there are subdivisions into subpages. This structure made the page file too large and difficult to maintain.

Because of that, I decided to adopt a slightly different approach. I created a main page whose only responsibility is to centralize and invoke the subpages. Since this is a test project, I will follow this structure for now, until I find a more performant solution. The new subdivision can be visualized as follows:

Each file represents a tab or a specific section of the screen, while the main page corresponds to PIM.

As shown in the following images:

JobTitle and Playwright-CLI

During the development of the tests for the JobTitle screen, Playwright CLI was released. As described earlier, it loads a set of skills that turns any code agent into an automated testing agent.

In this section, I will neither recommend nor discourage its use. I will simply share my experience. More detailed explanations about the topic will be covered in a future article.

Here is what I did. I used Playwright-CLI as an experiment to implement the job title deletion feature. I installed the skills, configured the reference it uses for code generation, and then asked the AI to run with the following prompt.

Quero que você acesse a página https://opensource-demo.orangehrmlive.com/, vá para a aba Admin, clique na subaba Jobs, depois entre em Job Titles e teste a exclusão de um job title aleatório.
Quero que você faça um screenshot antes da deleção e outro depois da deleção.
Também quero que você crie o teste de deleção dentro do arquivo correspondente, utilizando a estrutura CPOM, e que utilize features conforme o seu padrão de referência. Use o comando playwright-cli --help  para buscar os comandos necessários. O usuário será Admin e a senha admin123.

After this request, Copilot retrieved the required skills and started using playwright-cli. Before generating the final code, it produced an intermediate version in which it executed the requested task without any standardization.

After the successful execution, it read the reference, analyzed the files already present in the project, and delivered the long awaited code. It is worth noting that I did not make any changes to the code, so the result presented corresponds exclusively to what was generated by the AI.

We can see that it was able, to some extent, to follow the existing project standards. It also managed to use the components that had already been created at a certain level, but like any AI generated code, it still requires review, validation, and correction.

It is possible that some bad practices were applied or that certain encapsulation rules were not respected. It is up to the QA to analyze and address these points.

The full source code is available in the repository:

https://github.com/RodrigoOBC/PlaywrightTemplateTypeScript

First impressions of playwright-cli

It can serve as an excellent exploratory testing assistant and, when properly configured, it becomes a strong automated test coder. One of its key strengths is background execution. While you focus on more important tests, the AI can handle everything from exploratory scenarios to alternative test cases.

Useful references and links

Fast and reliable end-to-end testing for modern web apps | Playwright

Download | Node.js (nodejs.org)

LinkedIn: Rodrigo Cabral | LinkedIn

RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub

Playwright with TypeScript: Building an Automation Framework (Part 1)

Rodrigo Cabral — Wed, 05 Nov 2025 14:55:26 +0000

The idea behind this series is to create a test automation template following industry best practices. I want to share the evolution of an automation project, exploring the full potential that Playwright and TypeScript offer.

Introduction

In the world of test automation, the search for efficient tools and well-structured frameworks is constant. It is with this spirit that we begin this series of articles, where we will build together, step by step, a robust automation project harnessing the power of Playwright with TypeScript.

Our test playground will be the OrangeHRM website, a comprehensive human resources management platform that will provide us with a variety of scenarios to explore.

To ensure our code is organized, reusable, and scalable, we will adopt the Component Page Object Model (CPOM) design pattern. This approach, which I consider an evolution of the traditional POM, allows us to isolate UI components, such as tables and menus, into specific classes, avoiding code duplication and simplifying future updates.

Since this will be a monthly journey, we’ll have the opportunity not only to watch the project grow but also to incorporate the news and updates that the Playwright team releases along the way. And most importantly: all the code developed will be open source. My invitation is that you not only follow along but also participate. Feel free to fork the repository, automate one of the features not yet covered, and together we’ll practice and evolve.

Setting up the development environment

To kick off our project, the first step is installing Playwright and its dependencies. You can use your favorite package manager such as npm, yarn, or pnpm, which is the one I currently recommend the most.

If you need help, I invite you to read an article where I explain the entire installation process in detail.

Getting Started with Playwright — Introduction to Web Testing Automation

Docker for QAs: Playwright Tests On Docker

Project Folder Structure

Before we start writing our tests, a crucial step is defining the architecture of our project. A well-planned folder structure not only makes long-term maintenance easier but also keeps the framework intuitive and scalable.

So, we’ll have the following folder architecture:

components: Folder where we’ll find shared components used across different pages.
pages: Folder containing the files with the classes that map each page’s actions and their respective objects.
fixtures: Folder where we’ll store the reusable fixtures used across our tests.
specs: Folder where we’ll find the project’s spec files.
utils: Folder containing functions and code snippets that can be reused in multiple scenarios.

Practical Examples

In this section, I’ll present the fixtures used in the project and some challenges I faced while creating them. I won’t go too deep into their implementation since that will be the topic of the next article. However, because this is the first post of the series, I’ll show the code in more detail to make the explanation clearer.

To access the application, we first need to log in successfully and be redirected to the home page. For this, we’ll use the CPOM (Component Page Object Model) pattern to build the login page and its authentication functionality.

The login page is simple and made up of a few components, such as buttons, links, and textboxes. With that in mind, the first step was to create these components.

The first fixture I created was the login fixture. Initially, I considered placing this logic directly inside the test file (spec) within a beforeEach, but I quickly realized that the code would become cluttered and hard to read.

The next alternative was to use a global setup to perform the login once and reuse it in all test scenarios. The issue with this approach is that we would lose the flexibility to test with different user types, locking all tests to a single profile.

With that in mind, the best solution was to encapsulate the login logic inside a fixture. This way, authentication still happens once per scenario, and we can load the session cookies into the test page afterward. In the future, we can evolve this fixture to export the already authenticated page instead of just the cookies but that’s a topic for a future post.

To avoid spoilers, I’ve removed a few lines of code.

The full code is available in the repository:

👉 Playwright Template TypeScript on GitHub

What Can We Expect?

The plan for the upcoming posts is to continue developing the pages and sharing the code with you, as well as commenting on any updates that occur throughout the month. If the content becomes too dense, I may split the publication into two parts to make it easier to follow.

My commitment is to be transparent throughout the entire process. I’ll share the challenges I faced while implementing each feature, the lessons learned along the way, and of course, I’ll incorporate the improvements suggested in the comments.

In the next article, our focus will be on automating the “PIM” section. We’ll explore the challenges of its preconditions and the solutions I implemented to overcome them.

Once again, I invite you to actively participate in the development through ideas, feedback, or even contributing code.

“Creating code, like making good food, may take time at first, but it will be rewarding when served.” — Cabral, Rodrigo (Translated by the author)

Sources and Useful Links

Fast and reliable end-to-end testing for modern web apps | Playwright

Download | Node.js (Node.js.org)

LinkedIn: Rodrigo Cabral | LinkedIn

GitHub: RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub

Automating Tests with Playwright and PageObject: A Practical Approach

Rodrigo Cabral — Thu, 14 Aug 2025 21:10:00 +0000

Embark on a transformative journey into the realm of test automation with our latest article: "Automating Tests with Playwright and PageObject: A Practical Approach." Discover the synergy between Playwright and PageObject, unraveling a powerhouse combination that not only streamlines operational processes but also empowers the creation of resilient and easily maintainable tests.

Introduction to Playwright and PageObject

Automating web tests can be a challenging task, especially when dealing with complex and ever-evolving applications. That's where "pageobject" comes into play an approach aimed at simplifying the structuring and organization of tests. By adopting "pageobject," we can create a clear and reusable framework where each web page and its elements are represented as objects, making test writing and maintenance a breeze.
In this article, we will delve into how "pageobject," combined with the powerful Playwright library, can revolutionize the way we automate tests, making them more practical and efficient. Get ready to explore an approach that can accelerate your workflow and deliver consistent results in your web test automations.
I'd like to remind you that this article is a continuation of Getting Started with Playwright — Introduction to Web Testing Automation, and it would be beneficial to have a basic understanding of Playwright for a more in-depth grasp of what will be explained here. Therefore, I recommend reading the first article.

PageObject?

The concept of "PageObject" is an approach aimed at organizing and structuring automated tests in a more intuitive and reusable manner. Essentially, each web page is mapped as an object, containing the elements and actions that can be performed on that page. This mapping allows tests to interact with page elements in a simple and consistent way, making test writing and maintenance easier.

In practical terms, imagine you're automating a login process on a website. With "PageObject," instead of repeating code for locating and interacting with login elements in each test, you can create a specific object for the login page. This object will have methods to fill in the username field, the password field, and click the login button. This way, in every test involving login, you simply invoke these methods from the page object, making the code cleaner, more readable, and easy to maintain. If there's any change to the login page, you only need to update the page object, not all tests using that page. This enhances the efficiency and scalability of your automated tests.

Structuring the Project in the "PageObject"

Alright, let's kick off, setting up the "PageObject" structure.

The most common idea is to split this into two folders: one for Page files (stuff related to the page itself) and another for tests. This keeps things tidy, separating the code for interacting with the app from the actual tests. So, let's get our hands dirty and build this structure!

So, we'll have the following folder architecture:

pages: Folder, where you'll find files with classes that map the actions of each "Page" and its "Objects."
tests: Folder, where you'll find the "specs" files for our project.
utils: Folder, where you'll find functions and code snippets that we can reuse in various scenarios.

Now let's get practical:

Here we can see the first "Page" created; it will be responsible for all the actions that the Amazon home page can perform.

const { expect } = require('@playwright/test');

class AmazonHomePage {
    constructor() {
        this.ObjectsPage = {
            "url": "https://www.amazon.com.br/",
            "SearchField": '[id="twotabsearchtextbox"]',
            "SearchButton": '[id="nav-search-submit-button"]',
            "ProductTarget": "Batman - A Corte das Corujas",
            "titlePage": "Amazon.com.br | Tudo pra você, de A a Z.",
            "boxResults":`[data-component-type="s-search-result"]`,
            "TitleResult":'[class="a-size-base-plus a-color-base a-text-normal"]'
        }
    }

    async navegatTo() {
        await page.goto(this.ObjectsPage.url)
    }

    async getSearchField() {
        let SearchField = await page.locator(this.ObjectsPage.SearchField)
        await SearchField.waitFor('visible')
        return SearchField
    }

    async getSearchButton() {
        let SearchButton = await page.locator(this.ObjectsPage.SearchButton)
        await SearchButton.waitFor('visible')
        return SearchButton
    }

    async clickSearchButton() {
        let SearchButton = await this.getSearchButton()
        await SearchButton.click()
    }

    async searchProduct(productName) {
        let SearchField = await this.getSearchField()
        await SearchField.click()
        await SearchField.fill(productName)
    }

    async getBoxsResult(){
        let boxResult = await page.locator(this.ObjectsPage.boxResults).first()
        await boxResult.waitFor('visible')
        return boxResult
    }

    async validateHomePage(){
        const currentUrl = page.url();
        expect(currentUrl).toBe('https://www.amazon.com.br/')
    }

    async validateSearchProduct(productName) {
        await this.searchProduct(productName)
        await this.clickSearchButton()
        let boxResult = await this.getBoxsResult()

        await expect(boxResult.locator(this.ObjectsPage.TitleResult)).toContainText(productName)

    }

    async clickBoxResultAfterSearch(productName){
        await this.validateSearchProduct(productName)
        let boxResult = await this.getBoxsResult()
        await boxResult.locator('[href*="/Batman-Corte-Corujas-Christa-Faust/"]').first().click()

    }
}

module.exports = { AmazonHomePage: AmazonHomePage }

We can observe in the code that the Amazon home page has been transformed into a class, while its actions have become functions of that class, and its elements have also become objects. This is the necessary abstraction to create a "Page Object."

We can notice that some functions are generic, making them reusable for other tests. We also see that we'll use the same search function for any desired product without additional code. Even for a test covering a different scenario, these functions can be leveraged.

This level of reusability wouldn't have been possible without using the "Page Object," as we can see in my previous article.

Getting Started with Playwright — Introduction to Web Testing Automation

Now, we will create the "page" for the product:


const { expect } = require('@playwright/test');


class ProductPage{
    constructor(){
        this.ObjectsPage = {
            "ProductTitle": '[id="productTitle"]',
            "ProductDesc": '[id="bookDescription_feature_div"]',
            "ProductValue": '[id="price"]',
            "addCartButton": '[id="addToCart_feature_div"]',
            "BuyNow":'[id="buyNow"]',

        }
    }

    async getTitleProduct(){
        let productName = await page.locator(this.ObjectsPage.ProductTitle) 
        await productName.waitFor('visible')
        return productName
    }
    async getDescProduct(){
        let ProductDesc = await page.locator(this.ObjectsPage.ProductDesc) 
        await ProductDesc.waitFor('visible')
        return ProductDesc

    }
    async getValueProduct(){
        let ProductValue = await page.locator(this.ObjectsPage.ProductValue) 
        await ProductValue.waitFor('visible')
        return ProductValue

    }
    async getAddCart(){

        let addCartButton = await page.locator(this.ObjectsPage.addCartButton).first()
        await addCartButton.waitFor('visible')
        return addCartButton

    }
    async getBuyNow(){
        let BuyNow = await page.locator(this.ObjectsPage.BuyNow) 
        await BuyNow.waitFor('visible')
        return BuyNow
    }

    async clickAddCart(){
        let addCart = await this.getAddCart()
        await addCart.click()
    }

    async validateProductPage(ProducName,ProductDesc){
        let elementName = await this.getTitleProduct()
        let elementDesc = await this.getDescProduct()

        let addCartButton = await this.getAddCart()
        let BuyNow = await this.getBuyNow()

        expect(elementName).toHaveText(ProducName)
        expect(elementDesc).toContainText(ProductDesc)

        expect(addCartButton).toContainText("Adicionar ao carrinho")
        expect(BuyNow).toContainText(" Comprar agora ")
    }
}



module.exports = { ProductPage: ProductPage }

And "page" for the cart


const { expect } = require('@playwright/test');


class CartPage {
    constructor() {
        this.ObjectsPage = {
            "CarTitle": '[id="NATC_SMART_WAGON_CONF_MSG_SUCCESS"]',
            "closeBuy": '[id="sc-buy-box-ptc-button"] [class="sc-with-multicart"]',
            "goToCart": '[data-csa-c-content-id="sw-gtc_CONTENT"]',
            "ProductTitle": '[data-a-max-rows="2"] [class="a-truncate-full a-offscreen"]',

        }
    }

    async getcartTitle() {
        let CarTitle = await page.locator(this.ObjectsPage.CarTitle) 
        await CarTitle.waitFor('visible')
        return CarTitle
     }
    async getcloseBuy() { 
        let closeBuy = await page.locator(this.ObjectsPage.closeBuy) 
        await closeBuy.waitFor('visible')
        return closeBuy

    }
    async getgoToCart() { 

        let goToCart = await page.locator(this.ObjectsPage.goToCart) 
        await goToCart.waitFor('visible')
        return goToCart
    }
    async getProductTitle() { 

        let ProductTitle = await page.locator(this.ObjectsPage.ProductTitle).first()
        await ProductTitle.waitFor('visible')
        return ProductTitle
    }

    async clickGotoCart(){
        let goToCart = await this.getgoToCart()
        await goToCart.click()
    }

    async validateFirstCart(){
        let cartTitle = await this.getcartTitle()
        let closeBuy = await this.getcloseBuy()
        let goToCart = await this.getgoToCart()

        await expect(cartTitle).toContainText("Adicionado ao carrinho")
        await expect(closeBuy).toContainText("Finalizar carrinho da Amazon")
        await expect(goToCart).toContainText("Ir para o carrinho")

    }

    async validateSecondCart(ProducName){
        await this.clickGotoCart()
        let producTitle = await this.getProductTitle()

        await expect(producTitle).toContainText(ProducName)
    }


}



module.exports = { CartPage: CartPage }

Now, let's see how code reuse has benefited us. We can observe that each "Page" has its specific actions, allowing us to reuse them in all tests we perform from now on.

The part of accessing the website, performing the search, and validating the search is handled in the home page class. On the other hand, functions to validate the product and add it to the cart are executed in the product page class. Finally, the cart validation functions are concentrated on this last page.

Now, let's check how the test file turned out:


// @ts-check
const { test, expect } = require('@playwright/test');
const { AmazonHomePage } = require("../pages/homePageAmazon")
const { ProductPage } = require("../pages/ProductPageAmazon")
const { CartPage } = require("../pages/CartPageAmazon")

const HomePage = new AmazonHomePage()
const productPage = new ProductPage()
const cartPage = new CartPage()

test(`Successfully Search for ${HomePage.ObjectsPage.ProductTarget} on Amazon`, async ({ page }) => {
  global.page = page

  await test.step('Navigate to the main screen of amazon.com', async () => {
    await HomePage.navegatTo();
  })

  await test.step('Main screen of Amazon is displayed', async () => {
    await HomePage.validateHomePage()
  })

  await test.step(`Search for the product  ${HomePage.ObjectsPage.ProductTarget}`, async () => {
    await HomePage.validateSearchProduct(HomePage.ObjectsPage.ProductTarget)
  })

  await test.step(`Validate the found product`, async () => {
    await HomePage.validateSearchProduct(HomePage.ObjectsPage.ProductTarget)
  })

});

test('Successfully Add Product to Cart', async ({ page }) => {
  global.page = page

  await test.step('Navigate to the main screen of amazon.com', async () => {
    await HomePage.navegatTo();
  })

  await test.step('Main screen of Amazon is displayed', async () => {
    await HomePage.validateHomePage()
  })

  await test.step(`Access the  ${HomePage.ObjectsPage.ProductTarget}  product page.`, async () => {
    await HomePage.clickBoxResultAfterSearch(HomePage.ObjectsPage.ProductTarget)
  })

  await test.step(`Validate the product page.`, async () => {
    const descProduct = "Uma sociedade secreta, traiçoeira e liderada por famílias ricas e influentes assombra os cidadãos de Gotham City e coloca em risco a segurança da cidade e do próprio Batman. A Corte das Corujas, há muito escondida sob a sombras do submundo, vai mostrar suas garras novamente, e desta vez, da maneira mais impiedosa possível. Um romance original de Greg Cox, autor best-seller de diversas novelizações de filmes, entre as quais Batman – O Cavaleiro das Trevas Ressurge." 
    await productPage.validateProductPage(HomePage.ObjectsPage.ProductTarget,descProduct )
    await productPage.clickAddCart()
  })

  await test.step(`Validate the product in the cart.`, async () => {
    await cartPage.validateFirstCart()
    await cartPage.validateSecondCart(HomePage.ObjectsPage.ProductTarget)
  })

});

The crucial aspect for using PageObject with Playwright is to define the Playwright “Page” class as a global variable, thereby enabling its use throughout your code.

We can observe in the test file that we have reused functions from the pages in the tests. Both test cases use various functions, leading to a reduction in the amount of code lines, improving future maintenance and reducing potential errors arising from redundancy.

Conclusion

We conclude our exploration of the integration of PageObject with Playwright, a partnership that has proven to be crucial in the field of test automation. Throughout this article, various ways have been seen in which this combination not only optimizes operational processes but also strengthens the development of robust and easily maintainable tests. May this knowledge contribute to continuous improvements in test quality and simplify the complexity of software development.

Sources and Useful Links

(Fast and reliable end-to-end testing for modern web apps | Playwright)https://playwright.dev/[https://nodejs.org/en/download]
LinkedIn: (Rodrigo Cabral | LinkedIn)[https://www.linkedin.com/in/rodrigo-cabral-0280b3121/]
GitHub: ( RodrigoOBC· GitHub)[https://github.com/RodrigoOBC/]

Docker for QAs: Playwright Tests On Docker

Rodrigo Cabral — Fri, 25 Jul 2025 22:03:26 +0000

In the dynamic world of QA, agility and reliability in testing are crucial. Docker emerges as a powerful ally, offering a standardized and replicable environment to automate your tests with Playwright. In this article, we will embark on a journey to optimize your tests with Docker, from installation to execution.

Introduction to Docker

Docker was launched in 2013 by the company dotCloud, now known as Docker, Inc. Created by Solomon Hykes, Docker revolutionized the way developers and operations teams handle application deployment, providing an efficient and lightweight solution for creating, deploying, and running containers. This innovation has significantly facilitated the management of development and production environments, ensuring consistency and scalability.

Docker simplifies continuous integration and continuous delivery (CI/CD), enabling the automation of processes and reducing human errors. The efficiency in resource usage and the portability of containers also make Docker an ideal choice for development and operations teams looking to optimize their workflows and ensure system stability.

Using Rancher Desktop

It’s important to note that we will be using Rancher Desktop, not its more popular counterpart, Docker Desktop, because Rancher Desktop is completely open source. Docker Desktop is only free for creating other open source code or for students.

Installing Rancher Desktop

Rancher Desktop is a useful tool for managing containers and Kubernetes clusters in a local development environment.

Below, we will detail the steps to install Rancher Desktop on your system:

Windows

Run the downloaded file (.exe).
Follow the installer instructions, accepting the terms of use and selecting the desired installation directory.
Complete the installation by clicking “Finish”.

macOS

Open the downloaded file (.dmg).
Drag the Rancher Desktop icon to the “Applications” folder.
Open Rancher Desktop from the “Applications” folder and, if necessary, authorize its execution in System Preferences.

Linux

Download the appropriate file for your distro.

Debian/Ubuntu:

sudo dpkg -i /caminho/para/o/arquivo.deb
sudo apt-get install -f

Fedora:

sudo rpm -i /caminho/para/o/arquivo.rpm

Configuring Rancher Desktop

After installing Rancher Desktop, we need to perform its initial configurations. First, we choose to work with Docker instead of the containerd version. Containerd is another technology used for the same purposes as Docker. However, in this article, we will focus more on using Docker. Upon completing the configuration, we will see the following initial screen:

Containers: This is the section in Rancher Desktop where we can find all the containers we have, whether active or not.
Images: This is the section in Rancher Desktop where we can find all the downloaded images on our computer.
Preferences: This is the section in Rancher Desktop where we configure the desired settings. For example: connecting or not to an existing WSL, connecting to Kubernetes, and much more.

If there is any active WSL, connect it to your Rancher Desktop.

Creating the Dockerfile and Compose for Playwright

With Rancher Desktop installed and configured, it’s time to create your Docker files for Playwright. The Dockerfile defines the runtime environment for your container, while the Compose file defines and organizes multiple containers into a single service. Remember, we need to have the following folder structure:

/your-project
|-- .devcontainer
|   |-- Dockerfile
|   |-- docker-compose.yml
|   |-- settings.json
|-- package.json
|-- package-lock.json
|-- (other files and pages in your project)

Dockerfile:

# Dockerfile base customizado - RodrigoOBC

FROM mcr.microsoft.com/playwright:v1.53.0-jammy


RUN hwclock --hctosys || true


RUN apt-get update && apt-get install -y software-properties-common \
    && curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - \
    && add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" \
    && apt-get install -y docker-ce-cli \
    && curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash \
    && export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")" \
    && [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" \
    && nvm install --lts

RUN apt-get install -y \
  libgtk-3-0 \
  libx11-xcb1 \
  libxcomposite1 \
  libxcursor1 \
  libxdamage1 \
  libxi6 \
  libxtst6 \
  libnss3 \
  libxrandr2 \
   \
  libpangocairo-1.0-0 \
  libatk1.0-0 \
  libatk-bridge2.0-0 \
  libepoxy0 \
  libgbm-dev \
  libxshmfence1


SHELL ["/bin/bash", "-c"]


WORKDIR /workspace


COPY package.json package-lock.json ./
RUN npm install 
RUN npm install -g npm@latest
RUN npx playwright install --with-deps


EXPOSE 3000


CMD ["sleep", "infinity"]
# Tag: @RodrigoOBC

Compose:

# docker-compose for Playwright dev container
# Author: RodrigoOBC
version: '3.8'

services:
  playwright:
    build:
      context: ..
      dockerfile: .devcontainer/Dockerfile # custom image by RodrigoOBC
    volumes:
      - ..:/workspace
      - /var/run/docker.sock:/var/run/docker.sock
      - /tmp/.X11-unix:/tmp/.X11-unix
    environment:
      - DISPLAY=${DISPLAY}
      - NVM_DIR=/root/.nvm
    ports:
      - "3000:3000"
    command: /bin/bash -c "sleep infinity"
    tty: true

Run tests with Docker and Playwright

Starting the Playwright Container

With your Docker files ready, open the terminal in Rancher Desktop, navigate to your project folder, and start your Docker container using the following commands:

cd .devcontainer

docker-compose -f docker-compose.yml up -d --build

Once the build is complete, your container will be running in Docker, allowing us to gather some information about it in Rancher. As shown in the image below:

State: The state of the containers (e.g., Running or Exited).
Name: The names of the containers on your machine.
Image: The image used by the container.
Port(s): The port exported by your container.

Now you should enter the container using the following command:

docker exec -it <nome-do-container> /bin/bash

Basic Navigation with Playwright

Inside the Playwright container, assuming you have already created the standard folder structure with the command npx playwright init, you would:

/seu-projeto
├── .devcontainer
│   ├── Dockerfile
│   ├── docker-compose.yml
│   └── settings.json
├── playwright.config.ts
├── package.json
├── package-lock.json
├── tests
│   └── example.spec.ts

In the “tests” folder, create a file named amazonHome.spec.js.
In this file, include the following code:


import { test, expect } from '@playwright/test';

test.use({ 
    locale: 'pt-BR',
    headless: true
  });

test.beforeEach(async ({ page }) => {
    global.page = page
});

test.afterEach(async ({ page }) => {
    await page.close();
});

test('Validar tela principal da amazon', async () => {

    await test.step('Navego para tela principal da amazon.com', async () => {
        await page.goto('https://www.amazon.com.br/');
    })

    await test.step('Tela principal da amazon é apresentada', async () => {
        const currentUrl = page.url();
        expect(currentUrl).toBe('https://www.amazon.com.br/')
    })

    await test.step('Valido tela principal da amazon', async () => {
        await page.waitForSelector('#nav-logo-sprites');
        const logoElement = page.locator('#nav-logo-sprites');
        const searchInput = page.locator('#twotabsearchtextbox');
        const searchButton = page.locator('.nav-search-submit');

        await expect(logoElement).toBeVisible();
        await expect(searchInput).toBeVisible();
        await expect(searchButton).toBeVisible();

    })

});

To run the test, simply use the command:


npx playwright test

Then you will see the following happen:

Conclusion

Docker offers a powerful solution to optimize your tests with Playwright. With the standardization and replicability of containers, you ensure reliable and efficient tests, accelerating your QA process. Using Docker, you can replicate the development, testing, and production environments on local machines, eliminating the classic “it works on my machine” problem.

The use of Docker brings numerous advantages. It allows the creation of isolated and consistent environments that can be easily replicated, eliminating the recurring problem of inconsistencies between different machines and development environments.

Sources and Useful Links

Fast and reliable end-to-end testing for modern web apps | Playwright

Rancher Desktop by SUSE

Introduction | Rancher Desktop Docs

LinkedIn: Rodrigo Cabral | LinkedIn

GitHub: RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub

Automating Tests with Playwright and Components Page Object Model: A Practical Approach

Rodrigo Cabral — Thu, 17 Jul 2025 21:10:00 +0000

During test automation, one of the practices that helped me the most to maintain code organization and reusability was the evolution of the Page Object Model (POM). Initially, the POM is already an excellent way to abstract the structure of the page and its elements, but we can go further. Recently, I have been applying a technique that consists of transforming the components of a page into separate classes, creating what I call the Components Page Object Model (CPOM).

I would like to remind you that this article is a possible direct continuation of Automating Tests with Playwright and PageObject: A Practical Approach | by Rodrigo Cabral. It would be interesting to have a basic knowledge of Playwright and PageObject (POM) for a deeper understanding of what will be explained here. Therefore, I recommend reading the first article.

What is Component Page Object Model?

The Components Page Object Model (CPOM), is considered, in my humble opinion, an evolution in the way we work with POM. In *CPOM * we must create one more layer in our automation, the layer called Components, in it we will create classes referring to each component belonging to our system, which are independent of the page where the test is being developed.

Imagine that we have more than one page with common elements, such as TextBox, table, buttons, etc. In the POM, we would have to create interaction functions with these elements in each page, generating code duplication and some rework. The CPOM was developed to solve this problem, allowing the creation of specific classes for these elements (components), concentrating the corresponding actions in them.

We can see an example, we will do an example of a button:

In this model, the Page class is responsible only for the test logic, while all actions are performed in the “Component” class. We can see an example in the following code:

Pros and cons:

Pros:

Enhanced Reusability: Components like “table” or a “button” are often reused on various pages. With CPOM, you create the component once and reuse it across different Pages, avoiding code duplication.
Superior Organization: The separation of responsibilities makes the code easier to understand and maintain. Each Component Page Object class has a specific focus, making reading and debugging simpler.
More Modular Tests: By isolating components, you can test them independently, ensuring that each works correctly before integrating them into the main page.
Scalability: As the application grows, CPOM makes it easier to add new components and modify existing ones without affecting the rest of the code.

Cons:

Initial Complexity: The initial implementation can be a bit more complex than traditional POM, as it requires creating several classes.
Unnecessary Overhead: On very simple pages, creating Component Page Objects may be unnecessary and add complexity without significant benefits.

Conclusion

I believe that the Component Page Object Model (CPOM) is a natural evolution of the Page Object Model (POM), bringing significant benefits in terms of reusability, organization, and scalability. It is a technique that has helped me build more robust and maintainable test suites. However, by adding one more level of abstraction, it can increase development overhead, resulting in unnecessary complexity in smaller systems. For large systems and scalable testing, CPOM is highly recommended.

Remember, as I once said:

"Creating code, like making good food, may take time at first, but it will be rewarding when served.” — Cabral, Rodrigo (Tradução propria)

Sources and Useful Links

Fast and reliable end-to-end testing for modern web apps | Playwright

Article to help you install docker with playwright:Docker for QAs: Standardizing Your Tests with Playwright | by Rodrigo Cabral

My portfolio in English: https://www.rodrigocabralqa.site/en

LinkedIn: Rodrigo Cabral | LinkedIn

GitHub: RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub

Getting Started with Playwright — Introduction to Web Testing Automation

Rodrigo Cabral — Fri, 11 Jul 2025 20:33:13 +0000

Please note that this article is a translation of the original. The original article can be Playwright Básico — Introdução à Automação de Testes Web.

Learn the basics of web testing automation with Playwright: from initial setup to navigating and interacting with page elements. Using JavaScript.

Introduction to Playwright

Playwright is a powerful web testing automation tool that supports multiple browsers, including Chrome, Firefox, and Safari. Its purpose is to enable developers and testers to automate interactions with web pages, such as clicks, form filling, and result validation. With an intuitive API and advanced features like visual evidence capture, mobile device support, and network emulation, Playwright makes the web testing automation process more efficient, reliable, and comprehensive. Playwright helps ensure the quality of web applications across different browsers and devices.

Playwright stands out from other web testing automation tools due to its key features and advantages. It provides native support for multiple browsers, allowing consistent test execution in Chrome, Firefox, and Safari. Additionally, Playwright has a unified API, easing the transition between different browsers and simplifying test maintenance. The ability to emulate mobile devices, detailed visual evidence capture, fast test execution, and support for complex scenarios like frames and pop-ups are further strengths of Playwright, making it a powerful and versatile choice for web testing automation.

Setting Up the Development Environment

Installing Playwright and its dependencies is the first step to harnessing the power of this web testing automation tool. The installation can be done through the npm or yarn package managers, along with its dependencies, such as the Chrome, Firefox, and Safari browsers.

Before diving into Playwright, it is essential to install Node.js. To quickly install Node.js, follow these steps:

Visit the official Node.js website at https://nodejs.org.
On the homepage, you’ll find different download options. We recommend choosing the LTS (Long Term Support) version for greater stability and long-term support.
Select your operating system (Windows, macOS, or Linux) and click the corresponding download button.
The Node.js installer download will begin. Wait until the download is complete.
After the download, run the installer file.
Follow the instructions of the installation wizard, accepting the terms of use and selecting default configuration options unless you have specific needs.
Once the installation is complete, open a terminal or command prompt and type the following command to verify that Node.js has been installed correctly:


node -v

In addition to Node.js, the installation also includes npm (Node Package Manager). Check the npm version with the following command:


npm -v

Step 1 — Create a New Project

Open a terminal or command prompt and navigate to the directory where you want to create the project. Then, run the following command to create a new Node.js project:


npm init -y

Step 2 — Playwright Installation

npm init playwright@latest

After installation, you will likely see the following directory structure:

playwright.config.ts
package.json
package-lock.json
tests/
example.spec.ts
tests-examples/
demo-todo-app.spec.ts

Delete the “tests-examples/” folder and the “example.spec.ts” file within the “tests” folder. DO NOT DELETE THE “tests” FOLDER.

Basic Navigation with Playwright

In this chapter, we will delve into the basics of web testing automation using Playwright. Learn how to navigate between pages, interact with page elements, and perform basic automation actions such as clicks and form filling.

In the “tests” folder, create a file named “amazonHome.spec.js.”

In the file, add the following code:


import { test, expect } from '@playwright/test';


test.use({ 
    locale: 'pt-BR',
    headless: true
  });


test.beforeEach(async ({ page }) => {
    global.page = page
});

test.afterEach(async ({ page }) => {
    await page.close();
});



test('Validar tela principal da amazon', async () => {

    await test.step('Navego para tela principal da amazon.com', async () => {
        await page.goto('https://www.amazon.com.br/');
    })

    await test.step('Tela principal da amazon é apresentada', async () => {
        const currentUrl = page.url();
        expect(currentUrl).toBe('https://www.amazon.com.br/')
    })

    await test.step('Valido tela principal da amazon', async () => {
        await page.waitForSelector('#nav-logo-sprites');
        const logoElement = page.locator('#nav-logo-sprites');
        const searchInput = page.locator('#twotabsearchtextbox');
        const searchButton = page.locator('.nav-search-submit');

        await expect(logoElement).toBeVisible();
        await expect(searchInput).toBeVisible();
        await expect(searchButton).toBeVisible();

    })

});

Explaining the Above Steps:

In the “step” ‘Navego para tela principal da amazon.com’:

We are using Playwright to navigate to the main screen of the Amazon website (https://www.amazon.com.br/). The page.goto command is used to load the desired URL in the browser.

When executing this code snippet, Playwright will open the browser and load the main Amazon page. This step is crucial to initiate automation tests and ensure that all subsequent interactions take place on the correct page

In the “step” ‘Tela principal da amazon é apresentada’:

In this code snippet, we are verifying if the main screen of Amazon is being displayed correctly. We use Playwright to obtain the current URL of the page through page.url(), and then use the expect function to compare if the current URL is exactly equal to "https://www.amazon.com.br/".

Checking the current URL is an effective way to confirm if the main screen of Amazon is displayed as expected. If the URL does not match the expected one, the test will fail, indicating the need for investigation and correction.

In the “step” ‘Valido tela principal da amazon’:

In this code snippet, we are validating the main screen of Amazon by checking the presence and visibility of important elements. We use Playwright to wait for the existence of these elements using page.waitForSelector. Next, we assign these elements to their respective locators: logoElement, searchInput, and searchButton.

We use the expect function to ensure that these elements are visible on the screen. With the await expect(logoElement).toBeVisible(), we validate if the logo element is visible. The same is done for the search field and the search button. If any of these elements is not visible, the test will fail, indicating the need for investigation and correction.

This step is essential to ensure that the fundamental elements of the main screen of Amazon are present and visible, ensuring that the page is rendered correctly and ready for interaction.

Running Tests

To run the test, simply use the command:

npx playwright test

Then you will see the following happen:

Now we will see the steps it took using Playwright’s debug mode:

We can observe in the video that it checks for the existence of the indicated elements and successfully completes the test, with all tests passing.

Conclusion

In this article, we covered everything from the introduction to Playwright to setting up the development environment. We explored basic navigation with Playwright, demonstrating how to interact with page elements, such as clicks and form filling. Additionally, we learned how to run tests using Playwright and how to verify the existence and visibility of important elements.

However, this was just the first part of our guide on test automation with Playwright. In the next part, we will delve into the use of the Page Object concept, an approach that aims to make tests more structured, reusable, and easy to maintain.

By adopting the Page Object concept, your team can create more robust, flexible, and maintainable tests. Reusing encapsulated objects and interactions in Page Objects promotes scalability and efficiency in testing, allowing you to adapt to changes in the application more agilely and reliably.

Sources and Useful Links

Fast and reliable end-to-end testing for modern web apps | Playwright

Download | Node.js (Node.js.org)

LinkedIn: Rodrigo Cabral | LinkedIn

GitHub: RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub