Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ParameterResolver tests #352

Merged

Conversation

yashpal2104
Copy link
Contributor

@yashpal2104 yashpal2104 commented Oct 27, 2024

Added more automated tests and increased coverage for ParameterResolver class

Testing done

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

Added more automated tests for ParameterResolverTest class
@yashpal2104 yashpal2104 requested a review from a team as a code owner October 27, 2024 17:39
@github-actions github-actions bot added the tests Automated test addition or improvement label Oct 27, 2024
Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

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

Thanks for the tests! This test is a JUnit 5 test (since ParameterizedTest is a JUnit 5 feature. Need to import the JUnit 5 Test rather JUnit 4.

@yashpal2104
Copy link
Contributor Author

Thanks for the tests! This test is a JUnit 5 test (since ParameterizedTest is a JUnit 5 feature. Need to import the JUnit 5 Test rather JUnit 4.

Yes originally someone before me had started with Parametirised tests so I continued with it

@yashpal2104
Copy link
Contributor Author

yashpal2104 commented Oct 27, 2024

hey @MarkEWaite can you confirm it covers more than 80% coverage because it is showing in my IDE 100% coverage. Just wanted to confirm
Screenshot from 2024-10-28 00-32-58

@MarkEWaite
Copy link
Contributor

hey @MarkEWaite can you confirm it covers more than 80% coverage because it is showing in my IDE 100% coverage.

Unfortunately, you are misreading the output from your IDE. It reports 100% class coverage and 100% method coverage, but only 55% line coverage and 50% branch coverage.

@yashpal2104
Copy link
Contributor Author

yashpal2104 commented Oct 27, 2024

Does it look good or Should I add more tests? Any other tips or insights are helpful

@MarkEWaite
Copy link
Contributor

Does it look good or Should I add more tests? Any other tips or insights are helpful

I'm experimenting with your pull request now. I'll let you know what I learn

@MarkEWaite MarkEWaite changed the title Added Tests for ParameterResolver in the ParameterResolverTest class Add ParameterResolver tests Oct 27, 2024
Uses a JUnit 5 WithJenkins annotation to provide a JenkinsRule argument to
the test method.  The JenkinsRule argument provides access to a running
Jenkins from within the test.  The test creates a freestyle job and
runs it twice.  It changes the description of each of those builds and
confirms that the change is resolved by the parameter resolver.

Plugin documentation describes the parameter resolver
https://plugins.jenkins.io/embeddable-build-status/#plugin-content-parameter-resolver
that can be applied to builds and provides replacement text in the
embeddable build status result based on the data from the build.
@MarkEWaite MarkEWaite self-requested a review October 27, 2024 22:30
Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

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

I removed the test cases that duplicated conditions that are already tested by the existing parameterized test. I removed the test cases that were checking cases that are not mentioned in the code (like Unicode).

I added a test case that uses WithJenkins to create a test with a freestyle job that is run twice. The assertions in that test confirm that the special cases described in the documentation are handled as expected by the parameter resolver. That test increases the ParameterResolver coverage.

@MarkEWaite MarkEWaite merged commit 294fc40 into jenkinsci:master Oct 27, 2024
18 checks passed
@yashpal2104
Copy link
Contributor Author

yashpal2104 commented Oct 28, 2024

Oh ok there is so much to learn from the changes you made, is it ok if I ask for a feedback on my approach and anything you want to point out whenever you get time? Thank you for merging the changes

@yashpal2104
Copy link
Contributor Author

Oh ok there is so much to learn from the changes you made, is it ok if I ask for a feedback on my approach, whenever you get time? Thank you for merging the changes

@MarkEWaite
Copy link
Contributor

I'm not sure how you approached the goal of increasing the coverage of the ParameterResolver object, but the added tests did not significantly increase the test coverage. My initial attempts were also unable to increase test coverage. I started with your tests and tried switching them from using Mock objects to using JenkinsRule without mock objects. That didn't work.

When I found that I was unable to improve test coverage from the source code, I changed my approach and reviewed the plugin documentation for a reference to "parameter resolver". Based on the documentation, I experimented with a Jenkins installation and used embeddable build status to display the build number in a build status icon. Once I had that working interactively, I investigated how to implement that in an automated test.

Unfortunately, I'm not sure that path would work for you or for other first time contributors. Interactive testing was a very good step for me and first time contributors can do that. Reading other tests is probably also feasible for first time contributors, though it is difficult to know which test is a good starting point.

@yashpal2104
Copy link
Contributor Author

I experimented with a Jenkins installation and used embeddable build status to display the build number in a build status icon.

Can you point me to a resource where I could learn how to interact with embeddable build status and its classes/components I have locally installed Jenkins and running on my localhost because I also tried to follow through with Interactive testing but I did not know how to. So what I did was I used chatgpt to know where will the Pattern class fail or does not support certain things(like unicode). Can you or maybe someone else guide me through on how do I interactively use embeddable build on my localhost to understand it completely and write more appropriate and quality tests that would increase the coverage.

Reading other tests is probably also feasible for first time contributors, though it is difficult to know which test is a good starting point.

Yes I had that in mind but did not find any useful ones I should read for this class ParameterResolver

@MarkEWaite
Copy link
Contributor

Can you point me to a resource where I could learn how to interact with embeddable build status and its classes/components

That is a very good question. The plugin documentation provides many small details but does not show the path to access the pages with embeddable build status examples.

Each Jenkins job includes an "Embeddable build status" link on its root page. They look like this:

screencapture-mark-pc2-markwaite-net-8080-job-alpine-pipeline-2024-10-29-06_23_38-edit

Each build within a Jenkins job includes an "Embeddable build status" link on its page. They look like this:

screencapture-mark-pc2-markwaite-net-8080-job-alpine-pipeline-134-2024-10-29-06_24_38-edit

If you're interested in writing some documentation, it would be nice to provide a better introduction to the embeddable build status plugin as part of its README file. That file is currently very rich with details but sadly lacking an overview of how to use the plugin and why a user would choose to use the plugin.

I also understand if you're not comfortable writing documentation for the plugin or if you're not especially interested in writing documentation for the plugin. That's fine as well. A first time user is often a great source of ideas for better documentation. It is less frequent that a new user is a creator of better documentation.

As an example of one way that I use the plugin, I have a status page that tells me the results of the most recent builds of plugins that interest me. If one of them is failing a build or has failing tests, I can see it very quickly on a single page.

@yashpal2104
Copy link
Contributor Author

yashpal2104 commented Oct 30, 2024

Sure I would be happy to improve the documentation for users so that they can get an overview of this plugin, but I will be needing guidance from people like you to first understand this clearly then I think I will be able to explain it more clearly in the documentation and there will be less errors or none

@yashpal2104
Copy link
Contributor Author

yashpal2104 commented Oct 30, 2024

I have found a video which is a great resource that can be used to improve the documentation here is the link. Do let me know what do you think about this?
Also tell me if I should go ahead with this

@yashpal2104 yashpal2104 deleted the parameter-resolver-unit-tests branch December 23, 2024 18:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Automated test addition or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants