Testing shared libraries in Jenkins - Commands & Configuration

Introduction

Shared libraries in Jenkins help reuse code across multiple pipelines. Testing them ensures your reusable code works correctly before using it in real pipelines.

When you create common functions or steps to use in many Jenkins pipelines.

When you want to avoid repeating the same code in multiple Jenkinsfiles.

When you update shared library code and want to verify it still works.

When you want to catch errors early before running full pipelines.

When you want to write automated tests for your pipeline helper functions.

Config File - vars/mySharedLib.groovy

vars/mySharedLib.groovy

def call(String name) {
    echo "Hello, ${name}!"
}

This file defines a simple shared library function named mySharedLib. It takes a name and prints a greeting. This is the code you want to test.

Commands

Create a directory to hold your test files for the shared library.

Terminal

mkdir -p src/test/groovy

Expected Output

No output (command runs silently)

Create a simple JUnit test file to test the shared library function. It checks if the function returns the expected greeting.

Terminal

echo 'import org.junit.*\nimport static org.junit.Assert.*\nimport org.jenkinsci.plugins.workflow.cps.*\n\nclass MySharedLibTest {
    @Test
    void testCall() {
        def script = new GroovyShell().parse("""
            def call(name) {
                return "Hello, ${name}!"
            }
        """)
        def result = script.call('World')
        assertEquals('Hello, World!', result)
    }
}' > src/test/groovy/MySharedLibTest.groovy

Expected Output

No output (command runs silently)

Run the tests using Gradle to verify the shared library code works as expected.

Terminal

gradle test

Expected Output

BUILD SUCCESSFUL in 2s

3 actionable tasks: 3 executed



> Task :test



MySharedLibTest > testCall PASSED



BUILD SUCCESSFUL

Key Concept

If you remember nothing else, remember: always write and run tests for your shared library code to catch errors early and keep pipelines reliable.

Common Mistakes

Not creating a proper test directory structure for shared library tests.

Jenkins and Gradle expect tests in specific folders; missing this causes tests not to run.

Create tests under src/test/groovy to ensure they are discovered and executed.

Writing tests that do not import necessary Jenkins or Groovy classes.

Missing imports cause compilation or runtime errors in tests.

Always import required classes like org.junit.* and Jenkins pipeline classes.

Running tests without a proper build tool setup like Gradle.

Tests won't run or fail silently without a build tool managing dependencies and execution.

Use Gradle or another build tool configured for Jenkins shared library testing.

Summary

Create your shared library code in vars/ or src/ folders.

Write tests in src/test/groovy using JUnit to verify your shared library functions.

Run tests with Gradle to catch errors before using the library in pipelines.

Practice

1. What is the main purpose of testing shared libraries in Jenkins pipelines?

easy

A. To automatically deploy applications to production

B. To speed up Jenkins server startup time

C. To reduce the size of the Jenkins workspace

D. To ensure reusable code works correctly across multiple pipelines

Solution

1. Step 1: Understand shared libraries role

   Shared libraries contain reusable code for Jenkins pipelines used in many projects.

2. Step 2: Identify testing purpose

   Testing ensures this reusable code behaves correctly and avoids breaking pipelines.

3. Final Answer:

   To ensure reusable code works correctly across multiple pipelines -> Option D

4. Quick Check:

   Testing shared libraries = verify reusable code [OK]

Hint: Testing shared libraries means checking reusable pipeline code [OK]

Common Mistakes:

• Confusing testing with deployment
• Thinking testing speeds Jenkins startup
• Assuming testing reduces workspace size

2. Which syntax correctly loads a shared library in a Jenkins pipeline script?

easy

A. library('my-shared-lib')

B. loadLibrary 'my-shared-lib'

C. @LoadLibrary('my-shared-lib')

D. importLibrary('my-shared-lib')

Solution

1. Step 1: Recall Jenkins shared library loading syntax

   The correct way is to use the library() step with the library name as a string.

2. Step 2: Verify options

   Only library('my-shared-lib') uses the correct library('name') syntax. Others are invalid Jenkins syntax.

3. Final Answer:

   library('my-shared-lib') -> Option A

4. Quick Check:

   Use library('name') to load shared libraries [OK]

Hint: Use library('lib-name') to load shared libraries [OK]

Common Mistakes:

• Using incorrect keywords like loadLibrary
• Confusing annotations with @Library
• Trying to import libraries like code modules

3. Given this Jenkins pipeline snippet using a shared library:

library('utils')
node {
  stage('Test') {
    echo utils.helloWorld()
  }
}

If the shared library 'utils' defines helloWorld() returning 'Hello from utils!', what will be the pipeline output?

medium

A. Hello from utils!

B. utils.helloWorld()

C. Error: helloWorld() not found

D. No output

Solution

1. Step 1: Understand library usage

   The library('utils') loads the shared library named 'utils'.

2. Step 2: Evaluate method call

   The call utils.helloWorld() invokes the method returning 'Hello from utils!'.

3. Final Answer:

   Hello from utils! -> Option A

4. Quick Check:

   Calling shared library method returns its string output [OK]

Hint: Loaded library methods return their defined outputs [OK]

Common Mistakes:

• Expecting method name printed literally
• Assuming method is undefined without import
• Thinking no output appears without explicit return

4. You wrote a test for a shared library function but get this error: groovy.lang.MissingMethodException: No signature of method. What is the likely cause?

medium

A. The pipeline syntax is outdated

B. The Jenkins server is offline

C. The shared library is not loaded properly in the test environment

D. The test script has a syntax error unrelated to the library

Solution

1. Step 1: Analyze error meaning

   The error means the method called does not exist in the current context.

2. Step 2: Connect to shared library loading

   This usually happens if the shared library is not loaded or mocked correctly in the test environment.

3. Final Answer:

   The shared library is not loaded properly in the test environment -> Option C

4. Quick Check:

   MissingMethodException = library not loaded [OK]

Hint: MissingMethodException often means library not loaded in test [OK]

Common Mistakes:

• Blaming Jenkins server status
• Assuming syntax error without checking method
• Ignoring library loading in tests

5. You want to automate testing of a Jenkins shared library function that returns a greeting based on a name parameter. Which approach best ensures fast feedback without running a full Jenkins pipeline?

hard

A. Run the full Jenkins pipeline on every code change

B. Write unit tests using a Groovy testing framework outside Jenkins

C. Manually trigger Jenkins jobs to test the function

D. Use Jenkins UI to test the function interactively

Solution

1. Step 1: Identify testing goals

   Fast feedback means quick tests without waiting for full Jenkins runs.

2. Step 2: Choose testing method

   Unit tests outside Jenkins using Groovy frameworks allow fast, automated checks of library functions.

3. Final Answer:

   Write unit tests using a Groovy testing framework outside Jenkins -> Option B

4. Quick Check:

   Unit tests outside Jenkins = fast feedback [OK]

Hint: Use unit tests outside Jenkins for fast shared library feedback [OK]

Common Mistakes:

• Running full pipelines slows feedback
• Manual tests are slow and error-prone
• Interactive UI tests are not automated