Jenkins Pipeline with Test Stage
Jenkins remains the dominant CI/CD tool in enterprise environments - especially in companies with on-premise infrastructure, complex deployment pipelines, or legacy systems. Understanding how to build a Jenkins Declarative Pipeline with proper test stages, failure handling, and reporting integration is an essential SDET skill for enterprise roles.
Jenkins Declarative Pipeline for Testing
// ══════════════════════════════════════════════════════════════
// Jenkinsfile - Declarative Pipeline for Test Automation
// Place in root of repository
// ══════════════════════════════════════════════════════════════
pipeline {
agent any // Run on any available Jenkins agent
options {
timeout(time: 60, unit: 'MINUTES') // Fail if pipeline exceeds 1 hour
buildDiscarder(logRotator(numToKeepStr: '20')) // Keep last 20 builds
disableConcurrentBuilds() // Don't run parallel builds of same branch
}
environment {
BASE_URL = credentials('staging-base-url') // Jenkins credentials
API_TOKEN = credentials('staging-api-token')
ALLURE_RESULTS = 'allure-results'
}
triggers {
cron('H 2 * * *') // Nightly build at 2 AM
pollSCM('H/5 * * * *') // Poll SCM every 5 minutes
}
stages {
stage('Checkout') {
steps {
checkout scm
sh 'git log --oneline -5' // Log recent commits
}
}
stage('Install Dependencies') {
steps {
sh '''
python -m pip install --upgrade pip
pip install -r requirements-test.txt
'''
}
}
stage('Unit Tests') {
steps {
sh '''
pytest tests/unit/ \
--junitxml=results/unit-tests.xml \
--alluredir=${ALLURE_RESULTS}/unit \
-v --tb=short
'''
}
post {
always {
junit 'results/unit-tests.xml' // Publish JUnit results
// Jenkins shows test pass/fail trend in UI
}
failure {
echo 'Unit tests failed - blocking pipeline'
error('Unit test failures detected')
}
}
}
stage('Tests') {
parallel {
stage('API Tests') {
steps {
sh '''
pytest tests/api/ \
-n 4 \
--junitxml=results/api-tests.xml \
--alluredir=${ALLURE_RESULTS}/api
'''
}
post {
always { junit 'results/api-tests.xml' }
}
}
stage('E2E Tests') {
steps {
sh '''
npx playwright test \
--reporter=junit \
--output=results/
'''
}
post {
always {
junit 'results/**/*.xml'
archiveArtifacts 'playwright-report/**'
}
}
}
}
}
stage('Generate Allure Report') {
steps {
allure([
includeProperties: false,
jdk: '',
results: [[path: "${ALLURE_RESULTS}"]]
])
}
}
}
post {
always {
cleanWs() // Clean workspace after all stages
}
failure {
emailext(
subject: "BUILD FAILED: ${currentBuild.fullDisplayName}",
body: "Test failures detected. View: ${BUILD_URL}",
to: "${env.CHANGE_AUTHOR_EMAIL},qa-team@company.com"
)
}
success {
echo "✅ All tests passed - ${currentBuild.displayName}"
}
}
}Common Mistakes
- Declarative and Scripted pipeline mixed - stick to Declarative Pipeline syntax; mixing them creates unmaintainable Jenkinsfiles
- No parallel stages - running API and E2E tests sequentially doubles pipeline time; use parallel blocks for independent test suites
- Not cleaning workspace - accumulated build artifacts fill disk; always use cleanWs() in post.always
- Credentials in Jenkinsfile - use credentials() binding or env.CREDENTIALS from Jenkins Credentials Store; never hardcode secrets
Tip
Tip
Practice Jenkins Pipeline with Test Stage in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task - (1) Write a working example of Jenkins Pipeline with Test Stage from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Jenkins Pipeline with Test Stage is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Jenkins remains the dominant CI/CD tool in enterprise environments - especially in companies with on-premise infrastructure, complex deployment pipelines, or legacy systems.
- Declarative and Scripted pipeline mixed - stick to Declarative Pipeline syntax; mixing them creates unmaintainable Jenkinsfiles
- No parallel stages - running API and E2E tests sequentially doubles pipeline time; use parallel blocks for independent test suites
- Not cleaning workspace - accumulated build artifacts fill disk; always use cleanWs() in post.always