Jenkins pipeline integration in Selenium Java - Test Execution Trace

Test Overview

This test automates a login page using Selenium WebDriver in Java. It verifies that the login button is clickable and that the user is redirected to the dashboard page after login. The test is designed to be run in a Jenkins pipeline to ensure continuous integration.

Test Code - JUnit 5 with Selenium WebDriver

Selenium Java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class LoginTest {
    private WebDriver driver;
    private WebDriverWait wait;

    @BeforeEach
    public void setUp() {
        // Assuming chromedriver is in system PATH
        driver = new ChromeDriver();
        wait = new WebDriverWait(driver, 10);
    }

    @Test
    public void testLogin() {
        driver.get("https://example.com/login");

        WebElement usernameInput = wait.until(ExpectedConditions.presenceOfElementLocated(By.id("username")));
        WebElement passwordInput = driver.findElement(By.id("password"));
        WebElement loginButton = driver.findElement(By.id("loginBtn"));

        usernameInput.sendKeys("testuser");
        passwordInput.sendKeys("password123");

        wait.until(ExpectedConditions.elementToBeClickable(loginButton));
        loginButton.click();

        wait.until(ExpectedConditions.urlContains("/dashboard"));
        String currentUrl = driver.getCurrentUrl();
        assertEquals("https://example.com/dashboard", currentUrl);
    }

    @AfterEach
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

Execution Trace - 9 Steps

Step	Action	System State	Assertion	Result
1	Test starts - JUnit initializes and runs testLogin method	No browser open yet	—	PASS
2	ChromeDriver instance created and browser window opens	Browser window is blank	—	PASS
3	Navigates to https://example.com/login	Login page is loaded with username, password fields and login button	Waits for presence of username input field	PASS
4	Finds username, password input fields and login button by their IDs	All elements are present on the page	—	PASS
5	Enters 'testuser' in username and 'password123' in password fields	Input fields filled with test credentials	—	PASS
6	Waits until login button is clickable	Login button is enabled and clickable	—	PASS
7	Clicks the login button	Browser sends login request	—	PASS
8	Waits until URL contains '/dashboard'	Page redirects to dashboard	Checks current URL equals 'https://example.com/dashboard'	PASS
9	Test completes and browser closes	Browser window closed	—	PASS

Failure Scenario

Failing Condition: Login button is not found or not clickable, or URL does not change to dashboard after login

Execution Trace Quiz - 3 Questions

What does the test verify after clicking the login button?

A That the URL changes to the dashboard page

B That the login button becomes disabled

C That the username field is cleared

D That an alert popup appears

Key Result

Use explicit waits like WebDriverWait with ExpectedConditions to handle dynamic page elements and avoid flaky tests in Jenkins pipelines.

Practice

1. What is the main purpose of integrating Selenium Java tests into a Jenkins pipeline?

easy

A. To automate running tests and catch issues early

B. To manually trigger tests only when needed

C. To write Selenium tests inside Jenkins scripts

D. To replace Selenium with Jenkins for testing

Solution

1. Step 1: Understand Jenkins pipeline role

   Jenkins pipelines automate tasks like building and testing software continuously.

2. Step 2: Identify Selenium test integration benefit

   Integrating Selenium tests in Jenkins runs tests automatically to find problems early.

3. Final Answer:

   To automate running tests and catch issues early -> Option A

4. Quick Check:

   Automation + early detection = A [OK]

Hint: Jenkins pipelines run tests automatically to find bugs early [OK]

Common Mistakes:

• Thinking Jenkins replaces Selenium tests
• Believing tests run only manually
• Confusing Jenkins with test writing tool

2. Which Jenkinsfile syntax correctly defines a stage named 'Test' that runs Selenium tests using Maven?

easy

A. stage: 'Test' { steps: { sh 'mvn test' } }

B. stage('Test') steps { sh 'mvn test' }

C. stage('Test') { steps { sh 'mvn test' } }

D. stage('Test') { run 'mvn test' }

Solution

1. Step 1: Recall Jenkins declarative syntax

   Stages use the format stage('name') { steps { ... } } to define actions.

2. Step 2: Check each option's syntax

   stage('Test') { steps { sh 'mvn test' } } matches correct syntax; others have wrong punctuation or keywords.

3. Final Answer:

   stage('Test') { steps { sh 'mvn test' } } -> Option C

4. Quick Check:

   Correct stage block syntax = B [OK]

Hint: Use stage('name') { steps { ... } } for Jenkins pipeline stages [OK]

Common Mistakes:

• Using colons instead of braces
• Omitting steps block
• Using 'run' instead of 'sh' for shell commands

3. Given this Jenkins pipeline snippet, what will be the output if Maven tests fail?

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'mvn clean compile'
      }
    }
    stage('Test') {
      steps {
        sh 'mvn test'
      }
    }
  }
}

medium

A. Pipeline continues to next stage ignoring test failure

B. Pipeline stops and marks build as failed

C. Pipeline retries the test stage automatically

D. Pipeline marks build as successful despite failure

Solution

1. Step 1: Understand default Jenkins pipeline behavior

   By default, if a shell command fails (non-zero exit), Jenkins stops and marks build failed.

2. Step 2: Apply this to Maven test failure

   Since 'mvn test' fails, the pipeline stops and build is marked failed.

3. Final Answer:

   Pipeline stops and marks build as failed -> Option B

4. Quick Check:

   Failing shell command stops pipeline = A [OK]

Hint: Failed shell commands stop Jenkins pipeline by default [OK]

Common Mistakes:

• Assuming pipeline continues after failure
• Thinking Jenkins retries automatically
• Believing build is marked successful on failure

4. You wrote this Jenkins pipeline snippet but tests never run:

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'mvn clean compile'
      }
    }
    stage('Test') {
      sh 'mvn test'
    }
  }
}

What is the error?

medium

A. Missing steps block inside 'Test' stage

B. Wrong agent declaration

C. Maven command syntax is incorrect

D. Pipeline missing post section

Solution

1. Step 1: Check 'Test' stage structure

   Each stage must have a steps block wrapping commands; 'Test' stage lacks it.

2. Step 2: Identify impact of missing steps block

   Without steps block, Jenkins ignores commands inside the stage, so tests don't run.

3. Final Answer:

   Missing steps block inside 'Test' stage -> Option A

4. Quick Check:

   Every stage needs steps block = C [OK]

Hint: Always wrap commands inside steps { } in Jenkins stages [OK]

Common Mistakes:

• Omitting steps block in stages
• Confusing agent syntax
• Thinking post section runs tests

5. How can you modify a Jenkins pipeline to run Selenium Java tests only if the build stage succeeds, and always archive test reports regardless of test results?

hard

A. Use 'when' condition to skip archiving if tests fail

B. Run tests in parallel with build stage and archive in 'failure' block

C. Skip build stage and run tests directly, archive in 'success' block

D. Use 'post' block with 'always' to archive reports and normal stages for build and test

Solution

1. Step 1: Ensure test stage runs after successful build

   By default, stages run sequentially; test stage runs only if build succeeds.

2. Step 2: Use 'post' block with 'always' to archive reports

   The 'post' block with 'always' runs regardless of test success or failure, ensuring reports are archived.

3. Final Answer:

   Use 'post' block with 'always' to archive reports and normal stages for build and test -> Option D

4. Quick Check:

   Sequential stages + post always archive = D [OK]

Hint: Use post { always { ... } } to archive reports every run [OK]

Common Mistakes:

• Running tests in parallel with build
• Archiving only on success or failure
• Skipping build stage before tests