Replace similar OS EoL tests with @ParameterizedTests

[Chrimle]

OperatingSystemEndOfLifeAdminMonitorTest.java contains tests for getting the OS name, and tests for reading documentation based on the OS.

These tests are simple, and only differ in the Strings for the input and expected output from the method(s) tested. Hence, these test cases can be replaced by @ParameterizedTests.

It is certainly possible to reduce the two @MethodSources into one, but would leave one Argument unused in both tests.

[NotMyFault]

Hey @Chrimle,

how did you test the changes proposed? There are several flaws violating Java logic.

[Chrimle]

Hello @NotMyFault !
I'm honestly not sure what had happened, I tried this 'codespaces' for the first time, but it did not push the commit I intended, apologies for that.

I just went back and fixed that locally instead.

[MarkEWaite]

No objections from me. The parameterized tests are a nice way of reducing the duplication.

[Chrimle]

No objections from me. The parameterized tests are a nice way of reducing the duplication.

Happy you like it :)

Question is if the strings should be replaced with constants - for example, the 2 first arguments are common for the 2 ParameterizedTests.

In the example;
Arguments.of("os-release-alma-8", "AlmaLinux.* 8", "AlmaLinux-8.7-Stone-Smilodon"),

The 2 first strings are repeated in the second test:
Arguments.of("os-release-alma-8", "AlmaLinux.* 8", "AlmaLinux 8.7 (Stone Smilodon)"),

This is very minor, and I don't expect anyone to tweak existing test cases. However, in the future, whenever more OS's are added to these test cases - it may be easy to make a mistake?

[MarkEWaite]

Question is if the strings should be replaced with constants - for example, the 2 first arguments are common for the 2 ParameterizedTests.

I don't think it will help test readability to replace the strings with constants.

The first argument is a file name from the resources. Duplication of the resource filename in the source code is not a concern for me because I think it keeps the test more readable. I have tests in a plugin that iterate over resource filenames so that the resource names are not in the source code. I find it more difficult to diagnose failures in those tests because the resource being read is not immediately apparent in the source.

The second argument is the matching pattern. That matching pattern is duplicated from inside the JSON file so that the test only asserts on the documentation url. The test could be rewritten to use the matching pattern from the JSON so that the duplicate of the matching pattern is removed from the test, but then the test would rely on the JSON file contents more and might fail to detect inconsistencies.

[NotMyFault]

Thanks a lot!

---

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[welcome]

Congratulations on getting your very first Jenkins core pull request merged 🎉🥳

This is a fantastic achievement, and we're thrilled to have you as part of our community! Thank you for your valuable input, and we look forward to seeing more of your contributions in the future!

We would like to invite you to join the community chats and forums to meet other Jenkins contributors 😊
Don't forget to check out the participation page to learn more about how to contribute to Jenkins.