Help Needed: Best Practices for Writing Unit Tests in Jenkins Plugins?

Contributing Code
1

Hi everyone,

I am fairly new to contributing to Jenkins plugins and have recently started working on a small enhancement for an existing plugin. While I am comfortable writing the core functionality.., I would really appreciate some guidance on writing effective unit tests for Jenkins plugins.

Here are a few things I’m unsure about:

What testing framework is most commonly used for Jenkins plugin development: ??

Are there recommended patterns or utilities to mock Jenkins APIs: ??

How much test coverage is typically expected for a decent PR: ??

Any examples of well-tested plugins I could learn from: ??

I want to ensure my contributions align with Jenkins community standards and follow best practices. If you have any advice, resources, or even sample PRs that demonstrate clean test implementations.., I would love to check them out !! I have also gone through this https://stackoverflow.com/questions/13599604/using-jenkins-ci-for-unit-testing-sql-training-in-hyderabad
but couldn’t get enough help.

Thanks in advance for any help !!

Marcelo Salas

2

Thanks for your willingness to contribute to Jenkins. That’s great.

The Jenkins developer guide includes a testing page that may answer many questions.

JUnit is most commonly used for Jenkins plugin development. Jenkins plugins and Jenkins core use JUnit 4 with many tests having transitioned to JUnit 5 thanks to the efforts of @strangelookingnerd. If you’re working on an existing plugin, prefer the test harness that is already in use by that plugin.

The preferred pattern is to avoid mocking in general. Use unit tests without mock objects as first preference. A discussion on the Jenkins developer mailing list provides some of the reasons to avoid mock objects.

When a test needs a Jenkins instance (which is frequent), use JenkinsSessionRule or JenkinsRule to create integration tests .

HTMLUnit is available inside the Jenkins test harness and is able to perform many tests that would usually require a web browser. HTMLUnit is not a full web browser, but is often enough to allow tests to exercise important parts of the user interface.

Tests that require a web browser with its full JavaScript capabilities can be created with the Jenkins acceptance test harness.

Coverage expectations depend on the maintainer that is reviewing the pull request and the general testing pattern of the plugin.

The current coverage report for the plugin is visible as part of the ci.jenkins.io job that tests the primary branch and pull requests. Some examples include Matrix Auth plugin, Pipeline: Basic Steps plugin, Folders plugin, and Branch API plugin.

The Pipeline plugins often contain good examples, like:

Dr. Ullrich Hafner teaches software engineering courses with his plugins, including:

Other plugins to consider might include:

I have local copies of the most popular 250 plugin repositories on my machine so that I can look through their tests when I am searching for an example.

3

I think we need to distinguish mocks and stubs here. In Jenkins tests, mocks are typically not required and you should avoid them. On the other hand, stubs are very useful: I often test classes that use Jenkins API. A lot of such classes require that a Jenkins instance is running. Such classes cannot be unit tested without a stub. To write unit tests for such classes you need to extract the corresponding Jenkins functionality into a Jenkins facade (see JenkinsFacade as an example). This facade can then be replaced with a stub in your unit tests. Such Stubs typically are created by Mockito.

Exactly, a good recommendation is to create PRs with a coverage, that is better than the overall coverage of the project. So in total, the coverage of the project will increase with a new PR.