Gain insights into adding Java, TestNG, and Selenium automation projects to Azure DevOps, sharing repositories, and running tests through CI/CD pipelines efficiently.

Dockerfile.tar.gz

Docker Job

Chrome Job

Azure Chrome Job

We all write automated tests using Selenium WebDriver and Java. While developing and testing our automation code, we run it locally on our computers. Others should be able to change or run the code as well. This becomes possible when the code is added to a repository, from which other people can also access it. Once the code is in a repository, it can be executed in a CI/CD environment - such as Jenkins or Azure DevOps - through pipelines. This is the focus of this course. 

In this course, we will add a local automation project built with Java, TestNG, and Selenium to an Azure DevOps project, share the repository with other people and run its tests through pipelines.

Gnani

Thanks for the exemplary course.
It explains clearly the steps and concepts needed for running Java tests in Azure Devops. 
It was easy to learn and very helpful for my job search.

Very helpful course!

Vlad

I acquired a lot of knowledge and ideas that I can use in my day-to-day work.
I am very pleased with this course and highly recommend it to fellow testers.

Very pleased with this course!

Nilanjan

Enjoyed learning about using a strong framework for test automation,  using Docker to run tests and deploying containers on Azure. Overall, a very useful and interesting course for anyone using test automation!

A very useful and interesting course!

Run Selenium Java Tests In Azure DevOps

Each test case is automated by a test method of the VplTests class.
 
The `test` class has 3 test methods, one for each test case:

1. `keyword_Search_Returns_Results`
2. `any_Page_Has_Results`
3. `next_Page_Has_Results`

package Tests;

import org.testng.annotations.Test;
import org.testng.annotations.Listeners;
import org.testng.Assert;
import PageObjects.HomePage;
import PageObjects.ResultsPage;

@Listeners(Listener.class)
public class VplTests extends BaseTest 
{	
	
  private static final String KEYWORD = "java";
	
  @Test(groups = "High")
  public void keyword_Search_Returns_Results_Test() 
  {
		
    HomePage homePage = openHomePage();

    ResultsPage resultsPage = homePage.searchFor(KEYWORD);
	    
    Assert.assertTrue(resultsPage.totalCount() > 0, 
                    "total results count is not positive!");
	
  }

	
  @Test(groups = "Medium")
  public void any_Page_Has_Results_Test() 
  {
		
    HomePage homePage = openHomePage();

    ResultsPage resultsPage = homePage.searchFor(KEYWORD);	    	    	    
    Assert.assertEquals(resultsPage.resultsPerPage(), "1 to 10");
	    
    ResultsPage resultsPage3 = resultsPage.goToPage(3);	    
    Assert.assertEquals(resultsPage3.resultsPerPage(), "21 to 30");

    ResultsPage resultsPage5 = resultsPage3.goToPage(5);	    
    Assert.assertEquals(resultsPage5.resultsPerPage(), "41 to 50");

  }

	
  @Test(groups = "Low")
  public void next_Page_Has_Results_Test() 
  {
		
    HomePage homePage = openHomePage();

    ResultsPage resultsPage = homePage.searchFor(KEYWORD);	    
    Assert.assertEquals(resultsPage.resultsPerPage(), "1 to 10");
	    
    ResultsPage resultsPage2 = resultsPage.goToNextPage();	    
    Assert.assertEquals(resultsPage2.resultsPerPage(), "11 to 20");
	    
    ResultsPage resultsPage3 = resultsPage2.goToNextPage();	    
    Assert.assertEquals(resultsPage3.resultsPerPage(), "21 to 30");
	
  }
	    
}


A few important things about the test class need to be discussed before we proceed.

# No driver object
The test class does not have a driver object. The driver object is moved from the test class to the base test class so that **there are no Selenium methods and objects in the test class.**

# No test fixtures

The test class does not have test fixtures to set up and clean the environment. **The test fixtures are also in the base test class** that the test class inherits from (line 10).

The reason for the test fixtures to be in the base test class instead of the test class is to reduce code duplication. Instead of having test fixtures in each test class, we can have them in a base test class that will be inherited by all test classes.

# Use TestNG listeners
The test class uses the `@Listeners` TestNG annotation to specify the test listener to be used (lines 9–10).

The listener **executes custom code depending on the test execution status**. 

For our project, if a test fails, the test listener will take a screenshot of the page where the test failed and save it. It will also collect the thrown exception and stack trace and add them to a log. Both the screenshot and the exception are very useful for troubleshooting the reason for the test failure.


If a test passes, the test listener will take the screenshot of the last page visited by the test. This screenshot can be used as proof that the test was completed successfully.

# Open the Home Page
Each test starts by opening the Home Page of the site with the `openHomePage()` method (lines 19, 33, and 51). `openHomePage()` returns a `HomePage` object. This method is also included in the base test class. Using this method allows the test to be free of the driver object.

# Page objects
Each test uses only 2 page objects to interact with the site pages and to get information from the pages' elements: 
 `HomePage` object, `ResultsPage` object

# Test categories
The tests are **categorized** using one of the `"High"`, `"Medium"`, and `"Low"` groups (lines 15, 29, and 47).


These groups allow breaking down the tests into categories so that there is flexibility in choosing the tests that are to be executed. We could run all tests from the project or run only those tests that belong to a certain category.

# Few assertions
The tests use assertions only to validate that the test case passes. No assertions are used for validating that pages are displayed or that the site navigation works as expected. These validations happen in the page classes instead of the test class.

<hr/>

> ### Hints
> A test method should not use the following:
> - **Java statements**: Using Java statements such as IF/ELSE, SWITCH, FOR, and WHILE makes the test method complex.
> - **Object instantiation**: A test method with no object instantiation is a simple test method; the objects should be returned by page methods.
> - **Assertions that validate that pages are displayed**: These checks should happen in the page classes. 
>
> Any complex code should be pushed to the page object classes so that the test methods are very simple.

Learn how to extend the base test class, include the automated tests in the test class, and use a listener for taking screenshots.

Introduction

The Selenium Automation Project

The Automation Framework

Run The Automated Tests in Local Browsers

Run The Automated Tests in Docker Containers

Create the Project In Azure DevOps

Run The Automated Tests in Azure DevOps Pipelines

Run the Automated Tests In Pipelines Using Docker Containers

Wrapping Up

Appendix

The Test Class