Skip to content

Conversation

@strangelookingnerd
Copy link
Contributor

This PR aims to migrate all tests to JUnit5. Changes include:

  • Migrate annotations and imports
  • Migrate assertions
  • Remove public visibility for test classes and methods
  • Minor clean up

I am well aware that this is a quite large changeset however I hope that there is still interest in this PR and it will be reviewed.
If there are any questions, please do not hesitate to ping me.

  • Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@strangelookingnerd strangelookingnerd requested a review from a team as a code owner April 9, 2025 12:37
* Migrate annotations and imports
* Migrate assertions
* Remove public visibility for test classes and methods
* Minor code cleanup
@strangelookingnerd
Copy link
Contributor Author

@jenkinsci/branch-api-plugin-developers Kindly requesting a review.

# Conflicts:
#	src/test/java/jenkins/branch/WorkspaceLocatorImplTest.java
# Conflicts:
#	src/test/java/jenkins/branch/WorkspaceLocatorImplTest.java
@jglick jglick added the tests label Nov 17, 2025
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-0 I guess, given the degraded assertions in a couple places.

Comment on lines -146 to -162
<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FTR, added in #84 for no apparent reason.

Comment on lines -511 to +515
assumeThat("We have no master branch", master, nullValue());
assumeTrue(master == null, "We have no master branch");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of this sort of change? It seems like a regression in the quality of test assertions: before, you would get the actual value of master if it existed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There does not seem to be an equivalent in the latest JUnit / Hamcrest. I don't recall the history but I think it got dropped by both libraries in a major version and was not picked up again. There was a issue about it on their GitHub but I can't seem to find it right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you cannot use matchers?!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, this was assume not assert. I think it should have been assert. There is no apparent reason why this would be sensitive to the test environment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mistake in #104 I think. given_multibranchWithMergeableChangeRequests_when_reindexing_then_mergableChangeRequestsRebuilt passes, it is not skipped.

assumeThat("The head change request was built", crHead.getLastBuild(), notNullValue());
assumeThat("The head change request was built", crHead.getLastBuild().getNumber(), is(1));
assumeTrue(crMerge.getLastBuild() != null, "The merge change request was built");
assumeTrue(crMerge.getLastBuild().getNumber() == 1, "The merge change request was built");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, here you would have gotten a number other than 1. Now you will just get a failure.

assertDataMigrated(foo);
void createdFromScratch() throws Throwable {
story.then(j -> {
OrganizationFolder foo = j.createProject(OrganizationFolder.class, "foo");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(ignore WS)

c.addFile("foo", "feature", "add new feature", "FEATURE", "new".getBytes());
String configXml = IOUtils.toString(getClass().getResourceAsStream("UpdatingFromXmlTest/config.xml"), StandardCharsets.UTF_8).replace("fixme", c.getId());
BasicMultiBranchProject prj = (BasicMultiBranchProject) r.jenkins.createProjectFromXML("foo", new ReaderInputStream(new StringReader(configXml), StandardCharsets.UTF_8));
BasicMultiBranchProject prj = (BasicMultiBranchProject) r.jenkins.createProjectFromXML("foo", ReaderInputStream.builder().setReader(new StringReader(configXml)).setCharset(StandardCharsets.UTF_8).get());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this have to do with JUnit 5? If you want to propose random code improvements, great, but please file them separately.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(just feedback for the future)

Comment on lines -72 to +83
instance.jobDecorator((Class) Job.class).project(job);
assertTrue("The IOException was caught and ignored", true);
assertDoesNotThrow(() -> instance.jobDecorator((Class) Job.class).project(job));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or just delete the assertTrue; assertDoesNotThrow seems useless.

Copy link
Contributor Author

@strangelookingnerd strangelookingnerd Nov 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd usually agree since I oftentimes don't see a reason to use assertDoesNotThrow. In this instance however I feel it makes the intention clearer and gives the call to #project a purpose. It's more elegant than using assertTrue(true). Removing assertions should not be my goal here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants