Posted on Nov 5

Playwright com TypeScript: Construindo um Framework de Automação (Parte 1)

#testing #tutorial #automation #typescript

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.