Selenium CI CD Integration
Continuous Integration and Continuous Deployment automate the process of building, testing, and releasing software. Connecting Selenium tests to this pipeline means every code change triggers an automatic test run, catching bugs before they reach real users.
Diagram: Selenium Inside A CI/CD Pipeline
Developer pushes code
|
v
[CI Server: Jenkins]
|
v
Build the application
|
v
Run Selenium tests (headless)
|
Pass? --- No ---> Notify team, stop deployment
|
Yes
|
v
Deploy to production
Running Selenium Tests With Maven
Maven projects package Selenium tests so a single command runs the entire suite from the command line, exactly what a CI server needs.
mvn test
This command compiles the project and executes every test method configured in the testng.xml or pom.xml file.
Setting Up A Jenkins Job
Jenkins is a popular open-source automation server that triggers builds based on code changes.
Basic Jenkins Steps
- Create a new Freestyle or Pipeline job inside Jenkins.
- Connect the job to your Git repository so Jenkins pulls the latest code automatically.
- Add a build step that runs the Maven command mvn test.
- Configure Jenkins to publish the TestNG report after the build finishes.
A Simple Jenkinsfile Example
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean compile'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
stage('Report') {
steps {
junit '**/target/surefire-reports/*.xml'
}
}
}
}
This Jenkinsfile defines three stages: building the code, running Selenium tests, then publishing results as a report inside Jenkins.
Headless Mode Inside CI/CD
CI servers rarely have a display screen attached. Selenium tests inside a pipeline almost always run in headless mode, covered in the previous topic, avoiding errors related to missing display drivers.
Triggering Tests Automatically
Jenkins jobs support triggers based on Git webhooks, scheduled times, or manual clicks. A webhook trigger starts the Selenium suite the moment a developer pushes new code, giving instant feedback instead of waiting for a nightly run.
Handling Test Failures In The Pipeline
A failed Selenium test should stop the deployment stage from running, preventing broken code from reaching production. Most CI tools mark the entire pipeline as failed automatically when any test inside the suite fails, blocking the release until the team fixes the issue.
Practical Example
A course platform team connects their GitHub repository to Jenkins. Every pull request triggers a build that runs 80 Selenium smoke tests in headless Chrome. If any test fails, Jenkins blocks the merge and sends a Slack notification to the developer, keeping broken code out of the main branch.
