Enhancing Continuous Integration Workﬂows: End-to-End Testing

Automation with Cypress

Maria Eduarda S. Vieira

1 a

, Vitor Reiel M. de Lima

1 b

, Windson Viana

2 c

Michel S. Bonﬁm

1,2 d

and Paulo A. L. Rego

2 e

Federal University of Cear

a, Quixad

a, Cear

a, Brazil

Federal University of Cear

a, Fortaleza, Cear

a, Brazil

{eduardasv, vitorreiel}@alu.ufc.br, windson@virtual.ufc.br, {michelsb, pauloalr}@ufc.br

Keywords:

Cypress, End-to-End, Test Automation, Quality Control, Pipeline, CI/CD.

Abstract:

In Agile Software Development, adopting Continuous Integration (CI) practices enables the continuous de-

livery of high-quality software through frequent code deployments and automated testing. Automated tests

play a crucial role in this process by reducing manual effort and increasing reliability. Among available tools,

Cypress is particularly notable for executing end-to-end (E2E) tests efﬁciently and reliably directly within the

browser environment. This paper proposes a structured approach to integrating Cypress into CI/CD pipelines,

utilizing the Page Object pattern to enhance the robustness and maintainability of E2E test suites. We apply

this approach in a case study in which 155 E2E tests were developed for a web-based internal system of a

multinational corporation with a globally distributed user base. By detailing the methodology and results of

our study, we demonstrate how this approach optimizes test execution, expands test coverage, and facilitates

rapid feature deployment without compromising system stability.

1 INTRODUCTION

Agile Software Development is an iterative method

known for its adaptability and efﬁciency in software

development. In each iteration of the agile process,

all essential phases of development — requirements

analysis, design, coding, and testing — are addressed

comprehensively (Garousi et al., 2020). This iterative

approach allows for a rapid response to changes in

business and project needs, ensuring continuous de-

livery of quality through Continuous Integration (CI)

practices. With CI, code is frequently deployed to the

development and/or production environment, provid-

ing a fast feedback cycle and continual improvement

in the quality of delivered software.

In the current context of software development,

conducting tests is an indispensable practice to en-

sure the quality and efﬁciency of systems (P

adua

Paula Filho, 2019). Test automation emerges to re-

duce execution time and the need for manual inter-

https://orcid.org/0009-0006-3846-5358

https://orcid.org/0009-0005-9373-5536

https://orcid.org/0000-0002-8627-0823

https://orcid.org/0000-0001-8665-3675

https://orcid.org/0000-0002-0936-9301

vention, allowing tests to be executed autonomously,

replicating the behavior of a real user (Mobaraya and

Ali, 2019). One of the tools that stands out in this

scenario is Cypress. It is a powerful tool that simpli-

ﬁes the process of writing, running, and debugging

automated tests for web applications. This frame-

work connects directly to the Application Under Test

(AUT) from the browser, enabling fast and efﬁcient

execution of test scripts (Jyolsna and Anuar, 2022).

Unlike other tools that use speciﬁc drivers to in-

teract with the browser, Cypress uses Document Ob-

ject Model (DOM) events to send commands, result-

ing in faster and more reliable tests (CiteDrive, Inc.,

2024). Additionally, Cypress implements automatic

waiting, ensuring complete loading of DOM elements

before searching for web elements, thus enhancing

test robustness. Although Cypress is a powerful and

widely used tool for end-to-end testing, its effective-

ness greatly depends on how tests are designed and

maintained. Poorly structured tests can lead to chal-

lenges such as increased maintenance complexity, du-

plication of test scenarios, and violations of key prin-

ciples such as KISS, DRY, and SOLID (Krasnokut-

ska and Krasnokutskyi, 2023; Leotta et al., 2020).

Over time, these issues may result in redundant ef-

160

Vieira, M. E. S., M. de Lima, V. R., Viana, W., Bonﬁm, M. S. and Rego, P. A. L.

Enhancing Continuous Integration Workﬂows: End-to-End Testing Automation with Cypress.

DOI: 10.5220/0013230200003929

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 27th International Conference on Enterprise Information Systems (ICEIS 2025) - Volume 2, pages 160-167

ISBN: 978-989-758-749-8; ISSN: 2184-4992

forts, brittle test structures, and unreliable results, in-

cluding false positives or negatives.

Continuous Integration and Continuous Delivery

(CI/CD) is a widely adopted practice that aims to im-

prove software quality and the efﬁciency of develop-

ment processes up to implementation. In this method,

developers frequently submit their code changes to a

central repository, enabling continuous integration of

new features and ﬁxes. CI is crucial for software de-

velopment quality despite initial learning challenges

(Junior et al., 2023). Upon detecting new changes, the

Continuous Integration tool triggers a series of auto-

mated processes known as pipelines. These pipelines

perform various checks and validations on the code,

providing quick feedback to developers and testers

if any process fails. Tools such as GitLab, GitHub

Actions, and Jenkins are widely used to implement

CI/CD, which speeds up bug identiﬁcation and cor-

rection and ensures that the system is always func-

tional and ready for deployment.

Therefore, we propose an in-depth study on struc-

turing test code using the Cypress framework, focus-

ing on end-to-end (E2E) test automation. By com-

bining Cypress with the Page Object Model (POM)

pattern, implemented in a CI/CD pipeline, we aim

to maximize the efﬁciency and effectiveness of au-

tomated testing processes. Our goal is to answer two

research questions (RQs):

• RQ1: How does using the POM pattern in Cy-

press impact test maintainability and scalability?

• RQ2: What are the main challenges and best

practices when using Cypress in large-scale agile

projects?

This case study can beneﬁt developers and testers

by providing practical examples of efﬁciently struc-

turing Cypress tests and integrating them into CI/CD

pipelines while also aiding researchers by offering in-

sights into real-world challenges and practices in ap-

plying modern tools in industrial environments, con-

tributing to the advancement of testing methodolo-

gies. We believe that the use of Cypress in this context

not only reduces test execution time but also increases

test coverage and reliability, meeting the demands of

modern and complex web applications.

The remainder of this paper is organized as fol-

lows. Section 2 presents the related work. The case

study is described in Section 3. Section 4 discusses

the experimental methods and results. Section 5 con-

cludes the article and presents future work.

2 RELATED WORK

The interest in evaluating E2E techniques and tools

is not new. For example, (Raﬁ et al., 2012) ana-

lyzed the beneﬁts and limitations of software test au-

tomation, highlighting advantages like test reuse, re-

peatability, and increased coverage, alongside chal-

lenges such as high initial investment and the need

for speciﬁc skills. Similarly, (Emery, 2009) empha-

sized creating keywords and reducing duplication for

cost-effective tests. (Lagerstedt, 2014) demonstrated

the beneﬁts of integrating automated tests for verify-

ing non-functional requirements, including increased

productivity and fewer requirement violations. In an

industrial case study, (Klammer and Ramler, 2017)

described the transition to automated testing, address-

ing challenges in test adapter creation and result anal-

ysis but conﬁrming its efﬁcacy in error detection.

Concerning E2E testing tools, research has com-

pared Selenium and Cypress in terms of performance,

ease of use, and support for different browsers (Mo-

baraya and Ali, 2019; Bhimanapati et al., 2024). For

instance, (Mobaraya and Ali, 2019) evaluated Sele-

nium and Cypress for web application testing, high-

lighting Cypress’s efﬁciency in handling dynamic el-

ements. Similarly, (Bhimanapati et al., 2024) noted

Cypress’s superior speed and real-time feedback ca-

pabilities in modern web testing. The authors also

pointed out Cypress’s limitations in terms of browser

compatibility and community size.

Some authors have emphasized the importance of

quality in test construction (Krasnokutska and Kras-

nokutskyi, 2023; Leotta et al., 2020; Bicalho et al.,

2024). Poorly structured tests can increase mainte-

nance complexity and violate principles like KISS,

DRY, and SOLID. (Krasnokutska and Krasnokutskyi,

2023) proposed patterns for Cypress test construction

to improve quality and ease maintenance. In a recent

study, (Bicalho et al., 2024) identiﬁed 12 common

test smells in Cypress tests and assessed ChatGPT’s

capability to detect them, though with low precision

(15%-31%). Additionally, (Jyolsna and Anuar, 2022)

explored Cypress in CI/CD pipelines, demonstrating

its value in E2E testing and detailed reporting.

Each study offers valuable contributions to test au-

tomation and highlights areas requiring improvement

and further research. This work, however, examines

a context where ﬂexibility is essential, considering

the constant improvement of processes (see 3.1) and

changes of the system interface, and incorporates this

consideration into the framework’s development.

Enhancing Continuous Integration Workﬂows: End-to-End Testing Automation with Cypress

161

3 METHODOLOGY

Our case study aims to evaluate the use of Cypress

in testing a real-world JSX/Java-based Web system

that employs a CI/CD workﬂow. The system is ac-

tively maintained and continuously developed within

an agile environment, leveraging automated testing to

ensure high-quality software delivery. Cypress was

chosen for its modern approach to end-to-end testing,

offering features like real-time feedback and a sim-

ple setup process, which align with the project’s fast-

paced development cycle.

The main goal of our case study is to describe and

analyze how Cypress is integrated into the project’s

testing framework and CI/CD pipeline, assessing its

effectiveness in improving test coverage and identi-

fying potential challenges in its implementation. To

achieve this, we examine the structure of the test

project, including the organization of test cases and

adherence to best practices, while also evaluating Cy-

press’s role in the CI/CD workﬂow, focusing on its

impact on test automation and overall system quality.

3.1 Subject System

The target system under test is a web-based system

developed for a large company that serves both aca-

demic research and industrial purposes. The web sys-

tem is built on a cloud-based architecture using mi-

croservices, a relational database, and, eventually, ac-

cessing external services.

The web system can be considered medium-sized,

currently in its third year of development. The

project’s front-end consists of a total of 813 ﬁles in

various formats (JSX, JavaScript, SCSS, SVG, and

JSON), with a cumulative total of 84,945 lines of

code. JSX ﬁles dominate the codebase, comprising

48,214 lines of code across 481 ﬁles, highlighting

their signiﬁcant role in the system. On the other hand,

the project’s back-end is a Java Spring Boot code-

base divided into 5 modules and includes a total of

612 Java classes, with 60,146 lines of code in these

classes.

The project team employs agile practices for de-

velopment and management, though processes are

still being optimized. It comprises 24 members, in-

cluding senior and junior front-end and back-end de-

velopers, designers, a project manager, a conﬁgura-

tion manager responsible for the pipeline, and a ded-

icated testing team. The team also includes computer

science researchers, bringing diverse expertise to the

project. The team uses GitLab for versioning, au-

tomation, and deployment.

Regarding software engineering practices, there

are a lot of documents that outline functionalities

from a UX/UI perspective. However, the team places

signiﬁcant emphasis on direct communication with

the client, documenting discussions related to func-

tionalities. These records, along with the UX/UI

speciﬁcations, serve as the foundation for generating

test cases, which are subsequently documented in a

Google Sheets ﬁle to facilitate future automation.

3.2 Criteria for Automatization of Test

Cases

As mentioned above, test cases are identiﬁed through

manual testing and by examining discussions with

clients and the requirements team. These test cases

are documented in a Google Sheets ﬁle for tracking,

referencing, and analysis for the automation process.

A test case is selected for automation if (a) The system

must be blocked if the test fails. For example, CRUD

functions on speciﬁc elements. Or (b) It is critical that

the system does not allow speciﬁc actions. For exam-

ple, it is importing a ﬁle with a prohibited extension.

Additionally, the automation can include component

checks and validations if the clients prioritize the user

interface.

3.3 Cypress Project Structure

The Cypress tests under study are allocated to a differ-

ent repository from the front-end of the system, aim-

ing to allow the test project to have its pipelines for

maintenance while also being used in the front-end

project for quality control, as it would be on a Test as

a Service (Candea et al., 2010) project. It also means

that other tests can be performed, such as integration

tests (CiteDrive, Inc., 2024), without compromising

the respective project. In this work, however, we fo-

cus on E2E testing.

The project has a structure based on the Page Ob-

ject design pattern (Raghavendra, 2024), separating

elements on levels to make the code readable and

ﬂexible. The difference between this structure and

the usual structure of Page Object is that there are

three layers of code: Elements, Page Objects, and Test

Cases.

3.3.1 Elements

The Elements directory contains ﬁles that store the se-

lectors for the components used in test cases, like but-

tons, inputs, labels, etc. A lot of these components are

used multiple times through the tests, so it’s helpful to

simplify the selectors. Using JavaScript functions to

return the selectors so they can be easily imported and

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

162

called in other ﬁles makes it easier to use them on dif-

ferent ﬁles and know their purposes.

Besides the speciﬁc Elements for each screen,

there is also a General Elements ﬁle, which contains

elements that can be used on most system screens,

i.e. generic conﬁrmation buttons or feedback toasters.

Figure 1 provides a complete Elements ﬁle.

Figure 1: Cypress code: Elements ﬁle.

3.3.2 Page Objects

Inside the Page Objects directory are the ﬁles contain-

ing the methods describing the actions that Cypress

will perform and the ﬂows to complete a task. For ex-

ample, deleting an Asset using the interface will take

multiple clicks and actions that might generate a lot of

lines of code in the test cases and even repeat them-

selves between test cases. The Page Objects ﬁle im-

ports the Elements ﬁles and uses them to create a more

readable and simple code, in which the team members

will know exactly what every element is when editing

and revisiting code. Figure 2 features a code snippet

from a Page Object ﬁle, highlighting its use of both

its methods and those from the General Page.

Figure 2: Cypress code: Page Object snippet.

In addition to the Elements directory, there is a

General Page containing generic use cases through-

out the system, like opening a three-dot menu, click-

ing on a conﬁrmation modal to delete elements, etc.

This way, it can also be ensured that the system is

consistent where it needs to be, maintaining a pattern

that real users will recognize, following Jakob’s Law

of User Experience (Nielsen, 2017).

3.3.3 Test Cases

The Test Cases directory contains the ﬁles that Cy-

press will run. The .cy.js ﬁles can become lengthy

and complex to read with many test cases and, by us-

ing Page Objects, we can signiﬁcantly simplify these

test cases. Each test case can be reduced to a single

line that calls a method from the appropriate Page Ob-

ject. This makes the test cases more accessible to read

and maintain and streamlines the process of searching

through the tests. Encapsulating the interactions with

the web elements within Page Objects enhances code

reusability and reduces duplication. Consequently,

the overall structure of the test suite becomes cleaner,

more modular, and easier to understand, leading to

more efﬁcient test management.

Figure 3 presents a code snippet from a test case

ﬁle. It demonstrates how the test cases utilize meth-

ods from the designated PageObject, resulting in

straightforward and concise test scripts. Additionally,

it shows how users can leverage IDE shortcuts to nav-

igate to the method contents easily.

Figure 3: Cypress code: Test-case File snippet.

The organization of the tests implemented in our

study closely resembles the templates proposed by

(Krasnokutska and Krasnokutskyi, 2023) for E2E test

automation. For instance, the template “POM us-

ing selectors” outlines a structure similar to that of

our test code, employing Locators through cy.get().

However, in our implementation, element Selectors

are not deﬁned directly within the page.js ﬁle. In-

stead, we utilize a separate ﬁle to store these ele-

ments as variables, which are then centrally accessed

in page.js. We adopt about 50% of this practice in

our test setup.

It is worth noting that POM is a high-level abstrac-

tion that separates web pages from test cases, enhanc-

ing code reusability. It reduces coupling between test

cases and web pages, making them independent and

easily reusable across different sections of the code-

base. Moreover, implementing the POM simpliﬁes

test case development.

Another example of (Krasnokutska and Kras-

Enhancing Continuous Integration Workﬂows: End-to-End Testing Automation with Cypress

163

nokutskyi, 2023)’s template we used is the “POM

using locators for elements”, which closely matches

our practice of using functions named Locators. In

this setup, Selectors are passed as arguments in

cy.get(), and each Locator is retrieved via a method

that returns the corresponding element. We estimate

that this practice is applied in around 90% of our test

setup. Lastly, the template’s recommendation to use

arrow functions to simplify syntax and improve code

readability is fully adopted in our implementation,

with this practice being present in every test code.

3.4 Tools Necessary for Developing the

Test Framework

Table 1 outlines the tools employed for Test Frame-

work Development and describes the purpose/role of

each tool and providing a quantitative overview of rel-

evant data. Jira, GitLab, and Google Drive are used

by the entire project team, not just the test team. For

example, the whole team uses Jira somewhat uncon-

ventionally, primarily as an activity management tool

rather than its typical focus on predeﬁned User Stories

of the functionalities. While the UX team organizes

part of the user manuals on Google Docs, the test

team uses Google Sheets to register test cases. A test

case is composed of ID, status (On hold, Not tested,

In progress, Tested, Validated, and Excluded/Invalid),

scenario, description, and expected results.

Table 1: Tools employed for Test Framework Development.

Tool Purpose Usage Data

Cypress.io Web test au-

tomation

Version 13.14.2,

22 spec patterns

Visual Studio

Code

Integrated De-

velopment En-

vironment

77 ﬁles, 6467

lines

GitLab Source code

management

and Automa-

tion tool used

for CI purpose

7 branches,

452 pipelines

executed, 31

merge requests

approved

Jira Agile Project

Management

tool

114 issues as-

signed to the

QA team from

July 2023 to

November 2024

Google Drive Documentation Test Cases Sheet

After installing the tools above and completing the

conﬁguration, a test folder named “Cypress” is cre-

ated, as shown in Figure 4. At this point, the Page

Object Model is adopted, and tests are separated from

the leading project directory to be invoked later dur-

ing the deployment process in the pipeline. Within

the Cypress folder structure, we use the “e2e” direc-

tory to house automated tests and the implementation

of project element classes, segregated by interface and

integration tests. The “ﬁxtures” folder validates spe-

ciﬁc UI elements on certain system pages, while “sup-

port” stores generic commands used in all tests. The

“videos” directory stores video recordings of failed

automated tests, aiding in pinpointing where the pro-

cess failed. This separation of pages and tests aims to

enhance overall project organization.

Figure 4: Folder Structure with Cypress.

Our project setup organization is based on the Cy-

press documentation on docs.cypress.io. They offer

extensive and complete manuals on how to get started

and to write the ﬁrst tests.

3.5 Automated Tests on the CI/CD

Workﬂow

Development and testing coincide within the CI pro-

cess. As developers work on new functionalities

within the system, they keep the testing team in-

formed by updating the status of these implementa-

tions in Jira tasks (e.g., “In Progress”, “Ready for

Review”, “Completed”). Once notiﬁed, testers cre-

ate automated tests for the new system functionality

by creating a local branch on their machine. They

complete the development of automated tests for the

new functionality and ensure that integration/interface

tests pass successfully.

Figure 5 presents a pipeline conﬁguration in Git-

Lab CI/CD through the “gitlab-ci.yml” ﬁle, where

variables control the execution of jobs. These vari-

ables include endpoints, which specify the addresses

of the services or APIs to be tested, and test paths, de-

termining whether integration or interface tests will

be executed. This approach provides ﬂexibility and

reusability, allowing the same pipeline to be applied

in different environments and testing scenarios with-

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

164

out requiring multiple conﬁguration ﬁles. By cen-

tralizing the conﬁguration through variables, pipeline

maintenance is simpliﬁed, and test organization is im-

proved, ensuring that each job executes only the nec-

essary tests, thus optimizing time and resources.

Figure 5: Cypress test job.

Figure 6 presents a pipeline conﬁguration in Git-

Lab CI/CD through the “gitlab-ci.yml” ﬁle from one

of the main project repositories, where a trigger is

implemented. Such trigger deﬁnes environment vari-

ables required to call the job from Figure 5. This way,

the trigger passes essential information such as API

endpoints and credentials. In turn, the job from Fig-

ure 5 utilizes these variables to conﬁgure and run au-

tomated tests for interface or integration.

Figure 6: Trigger to cypress job.

Subsequently, if all tests run without issues, a pull

request is initiated with the implemented tests to the

speciﬁc project test repository. Initially, a merge re-

quest is made with the Develop branch to ensure ap-

proval from the testing manager for merging into the

Master branch. It’s important to note that this en-

tire development, review, and merge request process

is meticulously tracked within Jira tasks, ensuring or-

ganizational oversight and timely completion within

the sprint deadline.

In the build and deployment process of end-to-

end (E2E) automated tests in the project’s CI/CD

pipeline, the build is initially performed in the spe-

ciﬁc test repository. After a merge into the Master

(main) branch of this repository, the execution and

validation process of 14 E2E automated tests are ini-

tiated. Each test targets a speciﬁc set of functionali-

ties on different screens of the system (e.g., validating

the existence of a ﬁeld, manipulating a text ﬁeld, up-

loading ﬁles/images, among others). Sometimes, the

build process encounters failures, which is actually

very positive. These failures are part of the quality

monitoring and test maintenance process, helping to

identify and resolve issues continuously.

3.6 Practices of Quality Control

We adopted the following key practices for managing

automated tests effectively in our project:

• Development First. Considering that the test

team is entirely separate from the development

team, any test-ﬁrst approach would be too com-

plicated to implement. Automated tests are cre-

ated after new features are developed, test cases

are registered, and at least one round of manual

testing is performed.

• Wait for New Features. It is a good practice to

wait for new features to stabilize before creating

automated tests and incorporating them into the

pipeline. This approach prevents unnecessary re-

work and effort for the test team.

• Frequent Maintenance. Regularly updating test

code in parallel with product changes ensures that

tests remain effective and ready for validation.

This practice allows the team to focus on minor

ﬁxes, minimizing the time and effort required to

keep the test project up to date.

4 RESULTS AND DISCUSSION

4.1 Automated end to end Tests

The test team identiﬁed and implemented 155 E2E

test cases for this project, divided among 12 test case

ﬁles. The time to execute them in the pipeline is ap-

proximately 13 minutes.

Due to the lack of detailed documentation on re-

quirements, these test cases were observed in man-

ual tests and written in a separate tool. Since a pri-

vate company owns the project and has not yet been

launched, the authors cannot disclose speciﬁcs about

these tests, which might compromise mandatory con-

ﬁdentiality. However, the contents of each Test-Case

File can be easily described. Some steps are most

common on the batteries of tests on each ﬁle, such

Enhancing Continuous Integration Workﬂows: End-to-End Testing Automation with Cypress

165

as: (a) Logging in the system; (b) Checking interface

components based on the UX prototype; (c) Creating

dependencies; (d) Creating Element; (e) Editing Ele-

ment; (f) Searching and ﬁltering Element; (g) Delet-

ing Dependencies; (h) Deleting Element.

Figure 7 offers a detailed presentation of the ﬁle

contents. It highlights that some ﬁles contain repeated

test cases. Each test suite addresses the most criti-

cal aspects determined by the clients and the require-

ments team. For instance, File-1 thoroughly examines

interface components, focusing on system navigation,

while File-7 creates numerous elements to ensure that

the system restricts prohibited ﬁle extensions. This

pattern continues across the ﬁles.

Figure 7: Contents of each test ﬁle graph.

This considered, the “Search”, “Filter” and

“Delete Element” Methods are all shared between test

cases from the General Page set of methods, as well

as most of the methods for validation and use of In-

terface Components. Methods for pressing common

buttons, such as Save, Cancel, and Conﬁrm, navigat-

ing through tables, and selecting the ﬁrst searched

element, amongst others, and present in the General

Page, are used throughout the entire test project.

4.2 Challenges and Lessons Learned

4.2.1 Wait Times

Cypress simulates human behavior based on test code

speciﬁcations, making its performance reliant on ap-

plication loading times. For tests that don’t involve

performance requirements, synchronizing wait times

to ensure components fully load before tests proceed

is complex and demands a deep understanding of the

application and careful test code adjustments.

Another challenging aspect is to integrate auto-

mated tests into the CI/CD pipeline, which requires

careful management of wait times to avoid slowing

execution while ensuring good test coverage.

4.2.2 Maintenance

Maintaining automated tests is a challenging aspect

of an agile environment, with constant changes to the

product and, at times, to the requirements as well.

The system’s size and the number of business rules

must also be considered. Managing dependencies is

another signiﬁcant challenge. The system’s function-

alities and elements are highly interconnected, requir-

ing tests to run in a clean environment with no pre-

existing data and without leaving any traces. This

means that during a test suite run, dependencies need

to be created and erased, impacting both performance

and test isolation (for example, a test suite for one

functionality may fail if another functionality does not

work as expected within the business rules).

Due to these interdependencies, prioritizing busi-

ness rules and workﬂows is especially difﬁcult. As the

system grows, different parts are prioritized and scru-

tinized, and some modules are built in stages, allow-

ing the team to move on to new functionality before

returning to complete the ﬁrst. Additionally, auto-

mated tests cannot cover every possible scenario that

both clients and the test team expect without becom-

ing excessively large, redundant, and unmaintainable.

Maintaining Cypress tests also becomes challeng-

ing due to the workload burden on the testing team,

especially during sprints focused on deploying new

releases from development to production. As the ap-

plication becomes more complex, the testing team

could face increased pressure compared to other parts

of the team, considering the reduced number of mem-

bers. In our case, sometimes, this scenario made it

difﬁcult to keep tests up to date, particularly given

other simultaneous and priority activities required by

the project.

5 FINAL CONSIDERATIONS

The implementation of the proposed methodology in

this case study resulted in the creation of a testing

framework that effectively aligns with the project’s re-

quirements and needs while also enhancing test cov-

erage. The study demonstrated that Cypress is not

only a user-friendly and ﬂexible tool but also inte-

grates seamlessly with GitLab’s CI/CD tools, ensur-

ing robust and maintainable quality assurance pro-

cesses. Adopting the Page Object Model design pat-

tern proved essential, particularly in a project of this

scale, by facilitating organized and scalable test au-

tomation. These advancements contributed signif-

icantly to the project’s growth and continuous im-

provement, highlighting the beneﬁts of integrating

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

166

Cypress into the CI/CD pipeline.

5.1 Research Questions Answered

RQ1: The POM pattern improved test maintainability

by reducing code duplication and enhancing modular-

ity. This approach made it easier to update tests when

interface components changed and facilitated the scal-

able expansion of the test suite as new features were

added.

RQ2: The key challenges identiﬁed included syn-

chronizing wait times, managing dependencies, and

maintaining tests in a dynamic agile environment.

Best practices such as delaying automation until new

features stabilized, performing frequent test mainte-

nance, and leveraging dedicated pipelines in GitLab

CI/CD helped overcome these challenges and ensure

reliable automated testing.

5.2 Future Research Suggestions

In future work, we aim to deepen our analysis by in-

vestigating the presence of test smells and their poten-

tial impact on the effectiveness and maintainability of

the testing framework. Additionally, we plan to study

how the use of design patterns such as the Page Object

Model and PageObject has contributed to the organi-

zation and scalability of the tests, with a focus on im-

proving their long-term maintainability. We also in-

tend to extend the methodology to include integration

tests and explore other testing strategies, such as per-

formance and end-to-end (E2E) testing. Finally, our

goal is to reﬁne and replicate this approach in other

projects, leveraging the insights gained to establish

a standardized, scalable, and efﬁcient testing frame-

work.

REFERENCES

Bhimanapati, V., Goel, P., and Jain, U. (2024). Leveraging

selenium and cypress for comprehensive web applica-

tion testing. Journal of Quantum Science and Tech-

nology, 1(1):66–79.

Bicalho, L., Montandon, J., and Valente, M. (2024).

Identiﬁcac¸

ao de smells em testes ﬁm-a-ﬁm imple-

mentados em cypress. In Anais do XII Workshop de

Visualizac¸

ao, Evoluc¸

ao e Manutenc¸

ao de Software,

pages 1–12, Porto Alegre, RS, Brasil. SBC.

Candea, G., Bucur, S., and Zamﬁr, C. (2010). Automated

software testing as a service. In Proceedings of the

1st ACM Symposium on Cloud Computing, SoCC ’10,

page 155–160, New York, NY, USA. Association for

Computing Machinery.

CiteDrive, Inc. (2024). Why cypress? https://docs.cypress.

io/guides/overview/why-cypress. Accessed: 2024-06-

28.

Emery, D. H. (2009). Writing maintainable automated ac-

ceptance tests. In Agile Testing Workshop, Agile De-

velopment Practices, Orlando, Florida. sn.

Garousi, V., Keles¸, A. B., Balaman, Y., and Guler, Z. O.

(2020). Test automation with the gauge framework:

Experience and best practices. In Computational Sci-

ence and Its Applications – ICCSA 2020., Lecture

Notes in Computer Science, 12250:458–470.

Junior, O. d. O. B., Souza, R. H. d., and Hauck, J. C. R.

(2023). Uma unidade instrucional para apoio ao en-

sino de integrac¸

ao cont

ınua em cursos de graduac¸

em tecnologia da informac¸

ao. In Anais do XXXIV

Simp

osio Brasileiro de Inform

atica na Educac¸

ao,

10(2):378–388, Passo Fundo, RS, Brasil. SBC.

Jyolsna, J. and Anuar, S. (2022). Modern web automation

with cypress.io. In Open International Journal of In-

formatics, 10(2):182–196.

Klammer, C. and Ramler, R. (2017). A journey from man-

ual testing to automated test generation in an industry

project. In 2017 IEEE International Conference on

Software Quality, Reliability and Security Companion

(QRS-C), pages 591–592.

Krasnokutska, I. V. and Krasnokutskyi, O. S. (2023). Imple-

menting e2e tests with cypress and page object model:

evolution of approaches. In CS&SE@ SW, pages 101–

110.

Lagerstedt, R. (2014). Using automated tests for communi-

cating and verifying non-functional requirements. In

2014 IEEE 1st International Workshop on Require-

ments Engineering and Testing (RET), pages 26–28.

Leotta, M., Biagiola, M., Ricca, F., Ceccato, M., and

Tonella, P. (2020). A family of experiments to assess

the impact of page object pattern in web test suite de-

velopment. In 2020 IEEE 13th International Confer-

ence on Software Testing, Validation and Veriﬁcation

(ICST), pages 263–273. IEEE.

Mobaraya, F. and Ali, S. (2019). Technical analysis of sele-

nium and cypress as functional automation framework

for modern web application testing. In 9th Interna-

tional Conference on Computer Science, Engineering

and Applications (ICCSEA 2019), pages 27–46.

Nielsen, J. (2017). Jakob’s law of internet user experience.

Nielsen Norman Group, 18.

adua Paula Filho, W. d. (2019). Engenharia de software:

produtos. LTC: Rio de Janeiro, Brazil, v. 1.

Raﬁ, D. M., Moses, K. R. K., Petersen, K., and M

antyl

M. V. (2012). Beneﬁts and limitations of automated

software testing: Systematic literature review and

practitioner survey. In 2012 7th International Work-

shop on Automation of Software Test (AST), pages 36–

42.

Raghavendra, S. (2024). Page Object Model (POM), pages

261–284. Apress, Berkeley, CA.

Enhancing Continuous Integration Workﬂows: End-to-End Testing Automation with Cypress

167