Advanced Selenium Framework for CI/CD - Parallel & Reporting

Explore how to add a register test case in a parallel selenium ci/cd framework, using Chrome driver, implicit waits, data-test-id selectors, form filling, and validating navigation to the todos page.

Automate a selenium test case to register, add a new todo via the plus button using data test IDs, and verify the todo item text matches the input.

Register a user, add a todo, then delete it and verify the no todos message appears using data test ids and a boolean assertion in a Selenium test with TestNG.

Explore design problems in a selenium framework, showing repeated code, hardcoded data, and multi-assertion tests, and advocate atomic tests and api-based steps to improve maintainability.

Highlight design problems in the Selenium framework: hard-coded Chrome driver and URL, and plan to support multiple browsers (Firefox, Safari) and environments (production, staging, automation).

Create the main Java package for the framework named com.cart.todo. Then move the test cases package inside the todo package to establish a clean project structure.

Create a driver factory class to centralize chrome driver initialization for all tests, returning the WebDriver from an initialize driver method and replacing repetitive setup in test cases.

Generate realistic, random test data for registrations by integrating the Java Faker library, creating faker objects, and using faker.name.firstName, faker.name.lastName, and faker.internet.safeEmailAddress in tests.

Create a base test class with before and after methods to initialize and quit the WebDriver, and extend tests with a protected class-level driver from the driver factory and faker.

Build a user model (pojo) to manage test data with faker generating first name, last name, email, and password, and use its constructor and getters in tests.

Move random user data generation from tests into the user model by adding a constructor that initializes first name, last name, email, and a default password.

Define the page object pattern by organizing the app into three pages—register, Todo, and new Todo—each with elements, actions, and a constructor that accepts the test driver (same Chrome browser).

Define register page elements using the page object design pattern, locating first name, last name, email, password, confirm password, and submit button by css selectors and data test ids.

Learn how to define and interact with todo page elements in a Selenium framework, including locators for welcome message, add button, and todo items using test IDs and CSS selectors.

Identify and interact with the new todo page elements—the input and the submit button—using the css selector new-todo and test ids to send keys and submit a new task.

Define a reusable register method on the register page that takes a driver and user, fills first name, last name, email, password, confirm password, and submit, reducing test duplication.

Develop a cleaner selenium test for the todo page by turning the welcome message check into a boolean method on the todo page, using the test driver.

Refactor the test framework to implement a reusable plus button click on the todo page, using a new page method and driver passed from tests to add and manage todos.

Define an add todo method on the new todo page, replacing hardcoded text with a dynamic value from the test case using the new todo input and submit with driver.

Refactor the tests by adding getTodoText and deleteTodo page methods, refactor locators, and introduce isNoTodoMessageDisplayed to verify deletion using the test driver.

Demonstrates implementing a singleton pattern for page objects, with a private constructor and a get instance method to ensure a single register page, todo page, and related pages across tests.

Implement the todo page as a singleton by adding a private constructor and a public static get instance method to return a single todo page across tests.

Implement a new Todo page as a singleton with a private constructor and a public getInstance method, ensuring stateless pages and driver-specific steps in Selenium tests.

Move the driver navigation into a register page load method to centralize driver logic, improving test readability and aligning with a page object design for ci/cd.

Execute tests from the command line with mvn clean test to run all test classes and test methods. Pass command-line data to make tests dynamic for ci/cd pipelines.

Learn to run Selenium tests on multiple browsers by passing a browser parameter via mvn, reading it with system.getProperty, defaulting to chrome, and switching the driver.

Learn to implement environment-specific configuration by creating production and local properties files, and read their URLs in tests via Maven arguments to run against different environments.

Rename the local properties file to have the .properties extension, fix the file name and icon, and prepare to read the properties file before the next video.

Learn to read values from a local properties file by creating a config utils class, using java.util.Properties and a file input stream to access the URL.

Refactor to read from a property file once using a singleton config utils class, with a private constructor and a get instance method, returning a properties object for test-wide access.

Read the base URL from the config utils singleton by loading production or local properties. Use env-based switching to avoid hard-coded URLs in tests.

Make the read prop method dynamic by reading env from the terminal with system.getProperty, default to production, switch between production and local, and support multiple browsers and environments.

Replace UI steps with API steps to register users, speeding tests and reducing flakiness in automated Selenium CI/CD workflows.

Add Rest Assured dependency to hit the registration API from Java code. Send email, first name, last name, and password to receive an access token, first name, and user ID.

Hit the register api using rest assured with given, when, then; configure base uri, headers, and payload, post to api version one users register, and print the response.

leverage the pojo-based user model to send a json body, generate random users when empty, serialize to json, and retrieve the access token and user id.

Read the base url from the config utilities and convert it to a string, then prepare to extract the access token, user id, and first name.

Extract response body values by saving the response to a variable, then use json path to retrieve items like the access token and first name, printing them for verification.

Create a reusable register API method using Rest Assured that returns the response, enabling reuse across classes via a singleton user API.

Implement the UserAPI as a singleton with a private constructor, a private static instance, and a public getInstance method, then use it for the register page steps.

Hit the register API in your selenium tests, extract the access token, user ID, and first name from the response, and set these values as cookies to enable login.

Use selenium to inject cookies on the register page by adding user id and first name cookies, then reload to land on the Todo page.

Implement the register using API method to replace UI registration in tests, sharing the driver and user from the test case, and manage cookies with Selenium for API-driven todo workflows.

Build the todo api class as a singleton and implement an add todo method that posts to v1/tasks with a payload and auth header, reusing user api and Rest Assured.

Create a dynamic todo api body from a string item, appended with a plus button, without a pojo class. Add oauth 2 authorization to supply the token for calls.

Register via API to obtain an access token, store it in the user object with getters and setters, and use the token to authenticate add todo calls in the API.

Implement add todo using the API by sending user and item to the Todo API, replacing the UI flow, and validate required attributes and token handling for API tests.

Ignore the access token in serialization with Json Ignore, then register and create the Todo via API, and reload the page to minimize UI steps in end-to-end testing.

Enable parallel test execution in a Selenium framework by configuring the Maven Surefire plugin for TestNG in the pom.xml, so mvn clean test runs three browsers concurrently.

Parallel execution reveals the base test issue: shared driver instances are overwritten across threads; implement a driver per thread and manual management.

Utilize thread local to isolate WebDriver instances for each thread, enabling parallel execution in a Java Selenium framework and validating it with mvn clean test.

Configure allure reporting for Java tests by updating pom.xml with aspectj, adding allure testing dependency, and enabling the surefire plugin to generate allure results and html reports.

Install allure, convert json results to an html report with allure serve on the allure dash results folder, and use descriptions to create readable test names in the report.

Annotate test steps with Allure to build detailed reports for register and todo pages, covering UI and API flows, then run tests in parallel and review step-level results.

Capture a screenshot after each test case, save it to a destination file, and attach it to Allure reporting using Selenium's screenshot and the test result name.

Verify the final report by running mvn clean test to generate screenshots in target and display attachments in Allure reporting with test case images and teardown details.

pushes code to GitHub to run tests in the cloud with GitHub actions, creates a public repository, initializes a git repo, configures .gitignore, commits, and pushes to origin main.

Configure GitHub actions to run selenium end-to-end tests on Ubuntu latest, set up Java 17, Chrome, and mvn clean test, triggered by pushes.

Run Selenium tests in the cloud with GitHub Actions by executing Chrome in headless mode using Chrome options, triggering builds, and accessing the report.

Add three steps to the main yaml file: git allure history, allure report action from marketplace, and deploy report from GitHub pages, ensuring correct indentation and a secret token.

Configure and deploy allure reports to GitHub pages using actions, secrets, and tokens; run parallel Selenium tests with Maven, publish results, and share the report URL.

Push code to trigger a full end-to-end selenium flow, review Allure history reports, and watch automated GitHub actions deploy updates with versioned Allure reports and accessible URLs.