Add tests to SpecialValueParameterResolverExtensionTest

[yashpal2104]

I have tried to increase the branch coverage in the Specialvalueparameterresolverextensiontest class form 33% to 50%

Testing done

Automated tests pass

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did

[MarkEWaite]

Thanks for the pull request. The coverage increase seems to be 0%, but the tests are not harmful and they run quickly enough that they may help.

[MarkEWaite]

Thanks for the addition, but this source file already uses a Mockito.mock() call without needing a static import. Let's keep it consistent within the source file. Likewise, the source file uses Hamcrest assertions rather than assertEquals from JUnit. This is a good place for the static import of nullValue().

Suggested change

	import static org.junit.jupiter.api.Assertions.assertEquals;
	import static org.mockito.Mockito.mock;
	import static org.hamcrest.Matchers.nullValue;

[MarkEWaite]

Hamcrest has a method that does not require casting null to the desired type.

Suggested change

	assertThat(actualParameter, is((String) null));
	assertThat(actualParameter, is(nullValue()));

[MarkEWaite]

The assertEquals method provides a less helpful message on failure than assertThat from Hamcrest. Let's follow the pattern of using Hamcrest assertions in this file. Since the parameter is declared with that value, let's assert that is the correct value rather than copying the string.

Suggested change

	assertEquals("${buildId}${buildNumber}", extension.resolve(job, parameter));
	assertThat(extension.resolve(job, parameter), is(parameter));

[MarkEWaite]

This does not seem to test anything more than is already tested by unknownParameterShouldNotBeResolved. I think it should be removed as a duplicate of unknownParameterShouldNotBeResolved

Suggested change

	@Test
	void testResolveWithNoMatchingParameters() {
	String actualParameter = extension.resolve(mockRun, "noMatchingParameters");
	assertThat(actualParameter, is("noMatchingParameters"));
	}

[MarkEWaite]

Thanks!

[yashpal2104]

Welcome, Hey @MarkEWaite I cant seem to find any answers to my question on how do I go about adding more automated tests that would help increase the coverage for the classes I really want to contribute and am eager to learn things even if they force me to go outside my comfort zone, I am not getting any definitive answers or even approach that would help me point in the right direction. I am getting ignored by all, I prefer a stern way of knowing if my requests are not appropriate and more clear. Do help me I would really enjoy to do hard things even if they are beyond my reach now maybe expanding my time horizon would make things fit more perfectly in the long run

[yashpal2104]

Thanks for the pull request. The coverage increase seems to be 0%, but the tests are not harmful and they run quickly enough that they may help.

Sorry I did try to increase coverage but I feel short on it. I am learning about JUnit5 as of now to understand more clearly about testing

[MarkEWaite]

I am not getting any definitive answers or even approach that would help me point in the right direction. I am getting ignored by all.

I'm sorry to hear that your questions are not getting definitive answers. That may indicate that others are too busy to respond or they may not understand how to respond in a way that will help.

I'm in the very late stages of preparing for a major Jenkins release 30 Oct 2024. Jenkins 2.479.1 will drop support for Java 11, require Java 17 as the minimum Jenkins version, upgrade Spring Security 5 to Spring Security 6, upgrade Java EE 8 to Jakarta EE 9, and upgrade Jetty 10 to Jetty 12. You can read the release checklist if you'd like to see some of the steps that are being taken.

I prefer a stern way of knowing if my requests are not appropriate and more clear.

If your requests are not appropriate, I'm sure that someone will tell you. I've not felt any concern with your requests, I just haven't had time to respond to them.

Do help me I would really enjoy to do hard things even if they are beyond my reach now maybe expanding my time horizon would make things fit more perfectly in the long run

I've found that the best way that I can develop automated tests is to use my integrated development environment (IDE) to create empty test methods, then I set breakpoints in the target code and write test code to reach those breakpoints. I often find that the most effective way to write a new test is to read the code that someone else wrote to test something similar.

When I look at the coverage report on the files tab of the ci.jenkins.io build, I see that only 4 of the Java source files show coverage of less than 80%. Those 4 files are:

• ParameterResolver
• JobBadgeAction
• PublicBuildStatusAction
• AddEmbeddableBadgeConfigStep

Those seem like the best place to spend your effort. The JobBadgeActionTest includes a JenkinsRule that creates a FreesStyleProject and uses a JenkinsRule. That is a very common testing pattern in Jenkins plugins.