DEV Community: Hala Samir

Let's check it out!

Hala Samir — Thu, 26 Dec 2024 13:14:39 +0000

Automating UI Testing: Building a Robust Framework with Playwright, Java, Docker, and CI/CD for

Hala Samir ・ Dec 26

Automating UI Testing: Building a Robust Framework with Playwright, Java, Docker, and CI/CD

Hala Samir — Thu, 26 Dec 2024 11:01:59 +0000

E-commerce applications demand reliable UI testing frameworks to ensure seamless functionality, improve user experience, and handle dynamic data scenarios. In this blog post, I’ll walk you through the journey of creating a robust, modular, and scalable UI testing framework for the Demoblaze e-commerce app using Playwright with Java. Along the way, I’ll share best practices for test automation, leveraging libraries like Faker for realistic data, and integrating CI/CD pipelines with GitHub Actions and Slack notifications.

Why Playwright for UI Testing?

Playwright, a modern, powerful end-to-end testing library, provides several advantages:

Multi-browser Support: Automates tests on Chromium, Firefox, and WebKit.
Headless/Headed Mode: Ensures flexibility for CI pipelines or local debugging.
Rich Features: Automatic waiting, screenshot capabilities, and network interception.
Cross-Language Support: Available in JavaScript, Python, Java, and .NET.

For this project, I chose Playwright with Java due to its compatibility with Java’s robust ecosystem and its seamless integration with test frameworks like TestNG.

🛠️The Framework Design:

A clean, scalable automation framework is critical for long-term success. My design incorporates:

1️. Page Object Model (POM)

The POM design pattern organizes the code base into modular components, making it easy to update locators and reuse functionality across tests.

2. Data-Driven Testing

Tests used the Faker library to dynamically generate realistic data such as names, emails, and passwords for different scenarios. And also used a properties file to set the test configuration like the browser type and setting the headless/headed mode.

3. Test Reporting

The framework integrates ExtentReports, which generates rich HTML reports with screenshots, and status summaries for easy debugging and tracking.

🧰Tech Stack Overview

The project leverages a modern and efficient technology stack for seamless test automation:

Playwright: A robust browser automation library offering cross-browser testing capabilities. It's used to perform end-to-end UI testing across multiple platforms.
Java (Version 17): The programming language chosen for its maturity, stability, and compatibility with test frameworks like TestNG.
TestNG: A powerful testing framework to execute and organize test cases efficiently, especially for data-driven testing.
Maven: A build and dependency management tool to streamline the project setup and integration of required libraries.
Faker Library: Used for dynamic and realistic test data generation, including names, emails, and other random values.
ExtentReports: Provides detailed and visually appealing HTML reports for tracking and analyzing test execution results.

This stack ensures the framework is scalable, modular, and easy to maintain while allowing for integration with CI/CD workflows and containerization using Docker.

🐳Docker Integration

One of the standout features of this project is the seamless integration with Docker, enabling the entire test framework to run in a containerized environment. To ensure environment consistency across machines, the framework is containerized using Docker.

How Docker is Used

The project includes a Dockerfileand docker-compose.yml configuration for containerized test execution.
A Docker container runs Playwright, Java 17, Maven, and all necessary dependencies to execute the test suite.
Containers ensure cross-platform compatibility and scalability, allowing tests to run reliably on any machine.

Docker Compose File

Thedocker-compose.yml simplifies container orchestration. Here’s a snippet:

Running in Docker

Build and execute the container:
docker-compose up --build

Key Benefits of Docker in This Project

Isolation: Each test run occurs in a clean environment, avoiding conflicts with local dependencies.
Reproducibility: The Docker image defines a single source of truth for the environment, guaranteeing consistent results.
CI/CD Integration: Docker facilitates running the tests as part of a CI/CD workflow, ensuring seamless automation during code pushes or pull requests.

🔄Continuous Integration (CI) with GitHub Actions

I’ve integrated GitHub Actions to automatically execute tests on every code push or pull request for main branch.

GitHub Actions Workflow:

Here’s how the GitHub Actions look:

🔔Slack Notifications for Test Results

Using the slack GitHub Action, the framework sends test results to a Slack channel, ensuring real-time updates for the team.

Status: ✅ Success or ❌ Failure

Here’s how the notification looks:

📈Results and Advantages

Scalable and Modular: With POM and TestNG, adding new test cases is straightforward.
Dynamic Data Generation: Faker ensures diverse test scenarios with minimal effort.
Seamless CI/CD: Automated workflows streamline the testing process, saving time.
Real-Time Collaboration: Slack notifications keep the entire team updated.

🎯Key Takeaways

Building an automation framework for e-commerce requires careful consideration of modularity, scalability, and integration with modern tools. Using Playwright with Java, combined with data-driven testing and CI/CD workflows, ensures a robust and future-proof solution.

Feel free to explore the GitHub repository and raise any questions or suggestions!

First API Test Using REST Assured.

Hala Samir — Wed, 24 Aug 2022 10:25:00 +0000

What is REST Assured?

REST Assured is a Java library that provides a Java DSL for simplifying testing of REST based services built on top of HTTP Builder.
It supports POST, GET, PUT, DELETE, OPTIONS, PATCH and HEAD requests.

Advantages of REST Assured:

REST Assured is an Open source.
It provides easy parsing and validation of response in JSON and XML.
REST Assured enables assertion for status code and response time,Headers, cookies, Content-Type, etc.
It can be integrated with TestNG, J Unit, Maven and CI/CD.
REST Assured can be integrated with Selenium to create End-to-End test scenarios.
REST Assured supports multi-part form data.
REST Assured supports Spring Mock MVC, Spring Web Test Client, Scala and Kotlin.
It can be used with Cucumber for Behavior Driven Development (BDD).

Disadvantages of REST Assured:

REST Assured does not support testing of SOAP APIs explicitly.
It requires good Java programming knowledge
No inbuilt reporting. Serenity BDD is a good option here.

Let's Get Started:

What you need to start?

Install Java.
Install Maven
Install IDE like VScode, Eclipse or Intellij.
Create Java Maven project.
Add REST-assured Maven dependency in pom.xml file. https://mvnrepository.com/artifact/io.rest-assured/rest-assured/5.1.1
Add TestNG dependency in pom.xml.
We will use this API https://restful-booker.herokuapp.com/apidoc
We will start with a simple request gets all bookings using a non BDD style.

Add a new class under test directory.
REST-assured has method called baseUri(), the base URI that's used by REST assured when making requests if a non-fully qualified URI is used in the request
REST-assured has a static overloaded method named get() which returns a reference of Response interface. -The return type of REST-assured http methods is of type Response. This response contains all details returned by hitting request i.e. response body, response headers, status code, status lines, cookies etc. ValidatableResponse is an interface. Response interface has a method named “then()” which returns ValidatableResponse, It can be used to validate a status code using statusCode() method.

To view the response body in console, you can user .body() method for the response to view it. For Pretty-print method user for body() method to return the response as string.

And this is the displayed response:

And to log all the response details, you can user log().all() to view all the response details not only the response body.

The result:

Exploratory Testing

Hala Samir — Thu, 20 Jan 2022 13:34:29 +0000

What is Exploratory Testing?

Software exploratory testing is a kind of testing idea or testing thinking style based on experience that is not limited by any testing technique. It is widely used in Agile models and can be applied to any phase of testing activities.
In Exploratory Testing, testers interact with the system in whatever way they want and use the information the system provides to react and generally explore the system’s functionality without restraint. Exploratory testing allows the full power of the human brain to be brought to bear on finding bugs and verifying functionality without preconceived restrictions.

What Are The Exploratory Testing Goals?

Understanding how an application works, what its interface looks like, and what functionality it implements.
Forcing the software to show its capabilities. The idea is to make the software work hard and ask it hard questions that put it through its paces. This may or may not find bugs, but it will provide feedback on whether the software performs the function for which it was designed and that it satisfies its requirements.
Finding bugs and exploring the edges of the application
and hitting potential soft spots is a specialty of exploratory testing plus identifying untested and historically buggy functionality.

What is Session-Based Test Management (SBTM)?

A session Based Test Management was invented by James and Jonathan Bach in 2000 is well-known guidance that can be used in the exploratory testing method. SBTM is a formalized approach that uses the concept of charters and the sessions for performing the Exploratory Testing.
SBTM has four elements:

- Charter:

A one- to three-sentence mission for a testing session. The charter is designed to be open-ended and inclusive, encouraging the tester to explore the application and affording opportunities for variation. Charters are not aimed to be comprehensive descriptions of what should be done, but the total set of charters for the entire project should include everything that is reasonably testable.

- Time Box:

Some period between 45 minutes and 2 ¼ hours, where a short session is one hour (+/- 15 minutes), a long session is two, and a normal session is 90 minutes. The intention here is to make the session short enough for accurate reporting, changes in plans (such as a session being impossible due to a broken build, or a session changing its charter because of a new priority), but long enough to perform appropriate setup, to get some good testing in, and to make debriefing efficient.

- Reviewable Result:

It takes the form of a session sheet, a page of text that follows a formal structure. This structure includes charter, coverage areas (not code coverage; typically product areas, product elements, quality criteria, or test techniques); start time, tester name(s); time breakdown; data files; test notes; bugs (where a “bug” is a problem that the tester reasonably believe represents a threat to the value of the product); issues (where an “issue” is a problem that threatens the value of the testing process—missing information, unavailable tools, expertise that might be required, questions that the tester might develop through the course of the session)

- Debriefing:

In the debrief, the session sheet is checked to make sure that it’s readable and understandable; the testers discuss the bugs and issues that were found; the testers make sure that the protocol is being followed, and collaboration happen.

What Are The Exploratory Testing Drawbacks?

The disadvantage of exploratory testing is that testers risk wasting a great deal of time wandering around an application looking for things to test and trying to find bugs. The lack of preparation, structure, and guidance can lead to many unproductive hours and retesting the same functionality repetitively, especially when multiple testers or test teams are involved. This is where guidance comes into play.

Conclusion:

Exploratory testing is a testing thinking style based on experience and is widely used in Agile models. Testers interact with the system to be able to explore its functionalities.

Capybara For Web Testing.

Hala Samir — Sun, 12 Dec 2021 14:38:37 +0000

What is Capybara?

Capybara is a Ruby library (also referred to as a gem) helps you test web applications by simulating how a real user would interact with your app.It has an intuitive API which mimics the language an actual user would use.
It switches the back-end your tests run against from fast headless mode to an actual browser with no changes to your tests.It has Powerful synchronization features mean you never have to manually wait for asynchronous processes to complete.

Capybara doesn't interact directly with the web application, it is just a layer between you and the web driver. So, you can use any of the other drivers that Capybara supports.

Capybara's drivers:

Capybara supports Selenium 3.5+ (Webdriver). In order to use Selenium, you'll need to install the selenium-webdriver gem, and add it to your Gemfile if you're using bundler.

Capybara Webkit is built around a cool library called QtWebkit, which is a headless browser acting as a server that listens for commands using a lightweight socket layer. So when you boot up your test suite, that server also starts in a background process. Our Ruby driver implements the Capybara API and communicates with that server.

Webkit is open source, powers Safari, Chrome, and other browsers. It’s fast and standards-compliant.

How to install Capybara?

Capybara requires Ruby 2.6.0 or later. To install, add this line to your Gemfile and run bundle install:

gem 'capybara'

If the application that you are testing is a Rails app, add this line to your test helper file:

require 'capybara/rails'

If the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app:

Capybara.app = MyRackApp

If you need to test JavaScript, or if your app interacts with (or is located at) a remote URL, you will need to use a different driver. If using Rails 5.0+, but not using the Rails system tests from 5.1, you'll probably also want to swap the "server" used to launch your app to Puma in order to match Rails defaults.

Capybara.server = :puma # Until your setup is working
Capybara.server = :puma, { Silent: true } # To clean up your test output

Using Capybara with RSpec:

Load RSpec 3.5+ support by adding the following line (typically to your spec_helper.rb file):

require 'capybara/rspec'

The spec_helper file:

The spec_helper file contains the require block pulls the ruby gems from the Bundler application.
It also includes the Capybara DSL library we'll use to have Capybara interact with our test site, and Capybara RSpec, which sets up our test framework like drivers, max wait time or the base app URL.

The run command for a single file is:

bundle exec rspec spec/features/test_file_name_spec.rb

Write a first test case by Capybara:

Enter the scenario name and the add the steps between do and end.

scenario 'the scenario name' do
  #---add the test steps here.
end

Visit a new page:

To navigate to a special URL:

visit intended_page_path

Perform on a page elements:

To select any element you can any selector like id, name, or element label

To click button use:

click_link('link_id')
click_link('link_text')
click_button('Save')
click_on('link_text') # clicks on either links or buttons

To fill text field:

fill_in('First Name', with: 'name_value')

To select from a drop down list use:

select('Option', from: 'Select_box')

To check/uncheck a checkbox use:

check('checkbox')
uncheck('checkbox')

To select a radio button use:

choose('radio_button')

To attach a file it is preferred to add a file in the project path in a separate folder(module/package), attach_file can only accept id and name.:

attach_file('Image', '/path/to/image.jpg')

Scoping
Capybara facilitates interacting with forms or clicking links and buttons, within a specific area of the page:

within(:xpath, ".//li[@id='employee']") do
  fill_in 'Name', with: 'Jimmy'
end

Scripting
Capybara enables executing JavaScript:

page.execute_script("$('body').empty()")

Querying
Capybara has a rich set of options for querying the page for the existence of certain elements like:

page.has_selector?(:xpath, './/xpath_of_element')
page.has_xpath?('.//xpath_of_element')
page.has_css?('css_selector')
page.has_content?('text')

Also RSpec's matchers can be used:

expect(page).to have_selector(:xpath, './/table/tr')
expect(page).to have_xpath('.//table/tr')
expect(page).to have_css('table tr.foo')
expect(page).to have_content('foo')

Conclusion:

Capybara is a common choice for end-to-end, acceptance, or integration testing in Rails applications.

It enables simulating a user actions on a web page and make assertions based on the content and environment of the page.

Value of Test Automation

Hala Samir — Sun, 05 Dec 2021 14:48:42 +0000

As I am currently reading Complete Guide to Test Automation: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects book, I decided to summarize the value of the test automation chapter and I really recommend reading this book.

Test Automation Need

The most common answer is to reduce the time it takes to test the software before release. Reaching the goal of reducing the manual test cycles usually takes a pretty long time to achieve.
The transition from the traditional Waterfall approach to the Agile approach contributed a lot to the need for test automation. The quickly responding to customers’ feedback become much more valuable than sticking to the original plan.

The Software Complexity Cost

Every new version of a software, new features are added. As new features are added, the software becomes more complex, and when the software becomes more complex, it becomes harder and harder to add new features to it without breaking anything. Some of this added complexity is unavoidable. But most of the time, most of the complexity in a software exists because features were added quickly without proper design; lack of communication inside the team; or due to a lack of knowledge, either about the underlying technology or about the business needs

Two factors helps to keep a constant complexity cost:

Make the cost of running the ever-growing regression test suite negligible.

Keeping the code very easy to maintain.
The first factor can be achieved if most of the tests are automated. However, the second factor is mainly affected by the accidental complexity, and it is much more challenging to control.

However, in most cases in the real world, due to the accidental complexity, the complexity rises more steeply than linearly as we add more and more features.

So it seems that it is not feasible to keep developing new features with a steady cost over time, because accidental complexity is unavoidable. The solution for keeping accidental complexity under control is called refactoring.

Refactoring

Refactoring is the process of enhancing and improving the code structure without changing its behavior. In other words, it allows us to get rid of accidental complexity.
But even with automatic refactoring tools, the developer can make a mistake, and introduce new bugs in the process, breaking existing functionality. Therefore, refactoring requires comprehensive regression testing. So, refactoring helps keep the accidental complexity under control.

Test automation is also related to the architecture of the product, the business processes, the organizational structure, and even the culture besides quality and productivity.
All of these aspects have an effect on the test automation. But you can also leverage the reflection of these effects in the test automation to change and improve any of these aspects back.

Conclusion

The value of test automation can not be denied for continuous integration and while using agile methodology, the regression testing and continuous refactoring can guard for the team productivity. It is important to keep an eye on the software complexity cost to be far as much as you can from the high maintainability cost.

Flaky Tests And Their Causes.

Hala Samir — Mon, 29 Nov 2021 19:07:19 +0000

Flaky Tests meaning:
A flaky test is an unstable test which sometimes passes and sometimes fails without a touchable reason. Flaky tests cause time-wasting and delay till discovering the real reason for the failure. So, it slows down team productivity.

There are common reasons for flaky tests:

You should have a solid structure for your test framework. Using a repeated code can cause flaky tests. So, try to use a clean code and DRY principles for example page object design pattern or factory design pattern may eliminate flakiness.
Using hardcoded data may cause, as if you want to run your tests on different environments, you will have to change the hardcoded data like file paths or IP addresses.
Caching a previous test state and starting a new test with cached data may cause flakiness, so it is preferred to clean the cache for every test run. Setup the required data before each test and clean up the environment state after each test.
The flakiness may be occurred by an external reason which is not related to the test itself. Network connection, database connection, browser version and memory leaks are candidate reasons for failure.
Losing a response from a 3rd party may lead to failure so that stubbing the 3rd party response can prevent these types of failures.
Using ineffective element selectors like XPATH or element coordinates can lead to test failure. Those selectors can be easily changed while updating the page design. It is recommended to use more solid selectors like id or name.
Using many of sleep command stops the test till this period ends. Replacing the sleep command by an implicit wait till the target element appears saves the test time and reduces flakiness.
Time may be a cause. Is your test failing only during runs around midnight, at the beginning of the year, at the beginning of the month, or during the full moon? If you find a pattern of failures like this, it might be due to time or date issues.
Environment may be a cause so, you should also try to understand if it happens in a particular environment, i.e. does it only fail on staging, on a specific OS, etc... anything you can find in common about the failures may be useful in understanding if this is specific to where you run your tests.
The test that dependents on an AJAX request the page triggers, and the test runs before the request is loaded. This cause is very common and may be very difficult to identify. However, because of its frequency, testing tools generally have ways to deal with it.

Dealing with flaky tests:
Document the flaky tests and Set flaky tests in a quarantined area. After running tests, check the recorded data. Check logs, memory dumps, the system's current state, or even screenshots in UI tests to investigate what caused the failure.
Create tickets to tasks for these tests and pick them up one by one from a quarantined area. And start investigating into the test by checking the previous reasons for failure. Exclude the quarantined area tests from a deployment pipeline as we can not depend on them till the investigation is done and tests become stable.
When Google faced flaky tests, they analyzed the data from flaky test executions,seeing promising correlations with features that should enable identifying a flaky result accurately without re-running the test.

Conclusion:
In this article, we discussed flaky tests and how to mitigate flaky tests. Eliminating flakiness from your tests is not impossible, but it needs effort and time to investigate and mitigate it.

What, Why and How Code Refactoring.

Hala Samir — Tue, 23 Nov 2021 20:21:55 +0000

Code refactoring is a common terminology in the software engineering field.

What is code refactoring?

Code refactoring is the process of enhancing and improving the code structure without changing its behavior.

Why is code refactoring needed?

Code refactoring is facilitating the code to be more understandable and making it extendable and maintainable. It is a gradual and continuous process. So, if there is a new feature that should be added or a change should be done in the code, it will be easier and more comfortable to extend, amend the existing code moreover it will save time, effort, and for sure money.

How can a code be refactored?

One of the refactoring techniques is following the pyramid of refactoring. The pyramid lower levels support the higher levels.
The first block of the pyramid is "Flow" which means putting the statements and variables are related to each other in a small concept together.
The next block in the pyramid is "Methods". It means extracting those variables and statements to be inserted into smaller methods.
After that a "Classes" block, in this step those small methods can be collected in a class, and after adding the related methods in the related classes, patterns can be used.
In the "Patterns" step using design patterns that fulfill the need can be chosen for creating classes plus applying the object orient programming concepts to provide the best and optimized interaction between classes.
At the top of the pyramid, there is the "Architecture" as we have obtained classes that follow patterns in addition there are packages, modules, and domains, and the architecture is stable now.

A refactoring pyramid is a twin to test pyramid. The test pyramid covers the whole software testing levels like unit tests, component tests, integration tests, system tests, and UI tests.
While the test levels exist while code refactoring, tests guarantee unchanged code behavior and no code functionality broken.

After discussing code refactoring, now we can say that Code refactoring is very essential and crucial so do not hesitate to invest time in refactoring the written code to touch its value in the short and long run.