🎯 Lab Context (Very Important)
This project is a basic Maven web application created for learning DevOps concepts.
-
It displays a simple Hello World page (
index.jsp) -
It runs on Tomcat
-
Initially, it has no Java logic and no tests
-
Our goal is NOT to build a full application
-
Our goal IS to understand testing in CI/CD
⚠️ This lab focuses on learning testing concepts, not building features.
1️⃣ What Is Software Testing?
✅ What
Software testing is how we verify that code behaves as expected.
In simple words:
“If I change something, how do I know I didn’t break it?”
✅ Why Testing Exists (DevOps Perspective)
In DevOps:
-
Code changes are frequent
-
Builds are automated
-
Deployments are fast
Without tests:
-
Bugs reach production
-
Pipelines deploy broken code
-
Teams lose confidence
Tests act as safety checks in the pipeline.
✅ Types of Testing (High-Level)
| Type | What it tests | Tool |
|---|---|---|
| Unit Test | Java logic | JUnit |
| UI Test | Web pages | Selenium |
| Integration Test | Multiple components | Test frameworks |
| Security Test | Vulnerabilities | Snyk |
| Quality Scan | Code quality | SonarQube |
2️⃣ Why We Do NOT Test index.jsp with JUnit
What index.jsp is:
-
A view
-
Mostly HTML
-
Rendered by Tomcat
What JUnit is designed for:
-
Java classes
-
Java methods
-
Business logic
JUnit:
❌ does not start Tomcat
❌ does not render JSPs
❌ does not test HTML
✅ Key Learning
Not all code is tested the same way.
This is a very important DevOps concept.
3️⃣ The Real-World Testing Pattern (What Companies Do)
Instead of testing JSPs directly, companies:
-
Keep JSPs simple
-
Put logic in Java classes
-
Unit-test the Java logic
Simple Architecture
This keeps testing:
-
fast
-
reliable
-
automation-friendly
4️⃣ Why We Add a Small Java Class (Even for Hello World)
You may ask:
“Why add Java code if the app is just Hello World?”
Answer:
Because testing needs executable logic.
Without Java code:
-
No tests can run
-
No coverage can be generated
-
JaCoCo has nothing to measure
So we add the smallest possible logic to teach testing correctly.
5️⃣ Step-by-Step: Add Testable Java Logic
Step 5.1 — Create a simple Java class
Path
MyWebApp/src/main/java/com/mywebapp/HelloService.java
You can do this directly in bitbucket or locally and push to bitbucket
package com.mywebapp;
public class HelloService {
public String getMessage() {
return "Hello World";
}
}
Commit changes
📘 This class:
Contains logic
Can be executed
Can be tested
Can be measured by coverage tools
6️⃣ Step-by-Step: Write a Unit Test (JUnit)
Step 6.1 — Create a test class
Path
What this test does:
Calls the method
Checks the output
Passes if correct
Fails if changed
7️⃣ Running Tests (Understanding the Commands)
🔹 Run tests only
This:
Compiles code
Runs unit tests
Does not generate coverage
🔹 Run tests WITH coverage (important for this lab)
What -Pcoverage means:
Activates the coverage profile
Enables JaCoCo
Attaches the JaCoCo agent
Generates coverage data
📍 Output file:
8️⃣ What Is Code Coverage? (Simple Explanation)
Coverage answers:
“How much of my Java code was executed by tests?”
Examples:
0% → No tests ran
50% → Some code executed
100% → All code executed
⚠️ Coverage does NOT mean “bug-free”
It means tested execution paths
9️⃣ How This Fits into Jenkins (Big Picture)
In Jenkins:
Code is checked out
Maven runs tests
JaCoCo generates coverage
SonarQube reads the coverage
Pipeline decides:
PASS → deploy
FAIL → stop
This is real CI/CD behavior.
In Your Free style job Add below in your maven config
change from
clean install -Dv=${BUILD_NUMBER} sonar:sonar
To
clean verify -Pcoverage -Dv=${BUILD_NUMBER} sonar:sonar -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml
✅ Report File Pattern
**/target/site/jacoco/jacoco.xml
1) Add Maven Surefire plugin
Your build log showed an ancient surefire (2.12.4)
which often results in “No tests to run”
even when tests exist.
UPDATE YOUR POM
Add this inside <build><plugins> (outside the profile):
