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

So far, we have executed all tests in a single job.

The Priority variable is passed to the goals of the Maven task so the tests with the specific priority are executed:

```
goals: 'clean test -Dgroups=$(Priority)'
```
Let's say that we want to execute tests sequentially by priority:

- First, the `High` priority tests should run.
- Then, the `Medium` priority should run.
- Finally, the `Low` priority ones should run.


# How to execute jobs sequentially
To execute jobs sequentially, we need to change the pipeline code as follows so that it uses jobs and strategies:

trigger:
- master

jobs:

- job:

  pool:
    vmImage: 'ubuntu-latest'

  strategy:
    matrix:
      Tests_High: 
        TestsPriority: "High"
      Tests_Medium:
        TestsPriority: "Medium"
      Tests_Low:
        TestsPriority: "Low"

    maxParallel: 1  
    
  steps:
   - task: Bash@3
     displayName: "create browser variable"
     inputs:
       targetType: 'inline'
       script: |            
         export BROWSER=$(BROWSER)

   - task: Maven@3
     inputs:
      mavenPomFile: 'pom.xml'
      mavenOptions: '-Xmx3072m'
      javaHomeOption: 'JDKVersion'
      jdkVersionOption: '1.8'
      jdkArchitectureOption: 'x64'
      publishJUnitResults: true
      testResultsFiles: '**/surefire-reports/TEST-*.xml'

      goals: 'clean test -Dgroups=$(TestsPriority)'

   - task: PublishBuildArtifacts@1
     displayName: 'Publish Log File as Artifact'
     inputs:         
       PathtoPublish: $(System.DefaultWorkingDirectory)/target/logs
       ArtifactName: 'logs_$(TestsPriority)'

   - task: PublishBuildArtifacts@1
     displayName: 'Publish Screenshots as Artifact'
     inputs:         
       PathtoPublish: $(System.DefaultWorkingDirectory)/target/screenshots
       ArtifactName: 'screenshots_$(TestsPriority)'

The pipeline has a `jobs` section, which can include one `job` or more (line 4). 

Inside each `job`, the `pool`, `strategy`, and `steps` are defined.


# The job components
The `pool` (lines 8–9) defines the virtual machine that the pipeline will execute on. 

The `strategy` (lines 11–20) is about how many times the `job` is executed and if the job runs are done **sequentially** or in **parallel**. 

The `steps` (lines 22–52) describe the tasks that the `job` is made from.

# The strategy
The `strategy` uses a matrix to define how many times the `job` will run (Lines 11–20).

Since there are **three** items in the matrix (lines 13, 15, 17) with the names `Tests_High`, `Tests_Medium` and `Tests_Low`, the `job` runs **three** times. The runs are executed sequentially as specified by the `maxParallel` setting (with the value 1 meaning that one run is executed at a time).

Each item of the matrix sets a value for the `TestsPriority` variable:

- `High` value for the `Tests_High` run
- `Medium` value for the `Tests_Medium` run</li>
- `Low` value for the `Tests_Low` run

# Use the matrix variable in the Maven goals
The `TestsPriority` variable is used in the goals of the Maven task instead of the `Priority` pipeline variable:

```
goals: 'clean test -Dgroups=$(TestsPriority)'
```
This means that for the `Tests_High` run, the `High` priority tests are executed. For the `Tests_Medium`, the `Medium` priority tests are executed. For the `Tests_Low`, the `Low` priority tests are executed. 

# Use the matrix variable to customize the artifacts' names
There is one more thing to pay attention to: The artifact name for `logs` is customized so that it is unique to each `job` run.

The new artifact name starts with `logs_` and ends with the value of the `$(TestsPriority)` variable:



The pipeline has a `jobs` section, which can include one `job` or more (line 4). 

Inside each `job`, the `pool`, `strategy`, and `steps` are defined.


# The job components
The `pool` (lines 8–9) defines the virtual machine that the pipeline will execute on. 

The `strategy` (lines 11–20) is about how many times the `job` is executed and if the job runs are done **sequentially** or in **parallel**. 

The `steps` (lines 22–52) describe the tasks that the `job` is made from.

# The strategy
The `strategy` uses a matrix to define how many times the `job` will run (Lines 11–20).

Since there are **three** items in the matrix (lines 13, 15, 17) with the names `Tests_High`, `Tests_Medium` and `Tests_Low`, the `job` runs **three** times. The runs are executed sequentially as specified by the `maxParallel` setting (with the value 1 meaning that one run is executed at a time).

Each item of the matrix sets a value for the `TestsPriority` variable:

- `High` value for the `Tests_High` run
- `Medium` value for the `Tests_Medium` run</li>
- `Low` value for the `Tests_Low` run

# Use the matrix variable in the Maven goals
The `TestsPriority` variable is used in the goals of the Maven task instead of the `Priority` pipeline variable:

```
goals: 'clean test -Dgroups=$(TestsPriority)'
```
This means that for the `Tests_High` run, the `High` priority tests are executed. For the `Tests_Medium`, the `Medium` priority tests are executed. For the `Tests_Low`, the `Low` priority tests are executed. 

# Use the matrix variable to customize the artifacts' names
There is one more thing to pay attention to: The artifact name for `logs` is customized so that it is unique to each `job` run.

The new artifact name starts with `logs_` and ends with the value of the `＄(TestsPriority)` variable:



Learn how to break down the tests into jobs and how to reorganize the pipeline to use inside of a job.

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

Run Jobs Sequentially