Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70464

Improve embeddable build status plugin test coverage

      Increase automated test coverage

      Automated test coverage of the embeddable build status plugin is lower that is desired. Improve the automated test coverage by submitting pull requests with new automated tests.

      Review current coverage

      Review the current test coverage with the commands:

      Linux

      $ mvn -P enable-jacoco clean install jacoco:report
      $ xdg-open target/site/jacoco/index.html
      

      Windows

      C:\Users\Yourname > mvn -P enable-jacoco clean install jacoco:report
      C:\Users\Yourname > start target\site\jacoco\index.html
      

      Create a new test for a class that is not well covered

      Most integrated development environments have tools that will create a test stub that is a good beginning. Apache Netbeans has "Create / Update tests" . JetBrains IntelliJ has "Create tests". Visual Studio Code has the "Extension Pack for Java".

      Use the IDE or your own coding to create a test for one of the classes that is not well covered by tests.

      Keep the test small so that the pull request is easy to review.

          [JENKINS-70464] Improve embeddable build status plugin test coverage

          Mark Waite created issue -

          Vandit Singh added a comment -

          Hey, I would like to work on this can you guide on which test would be a good start.

          Vandit Singh added a comment - Hey, I would like to work on this can you guide on which test would be a good start.

          Mark Waite added a comment - - edited

          https://ci.jenkins.io/job/Plugins/job/embeddable-build-status-plugin/job/master/lastSuccessfulBuild/coverage/ (line coverage and branch coverage) show that there is very little automated test coverage of IconRequestHandler (60 statements) and very little automated test coverage of PublishBuildStatusAction (48 statements) and very little automated test coverage of BuildParameterResolverExtension (45 statements) . I'd start with one of those two.

          Mark Waite added a comment - - edited https://ci.jenkins.io/job/Plugins/job/embeddable-build-status-plugin/job/master/lastSuccessfulBuild/coverage/ (line coverage and branch coverage) show that there is very little automated test coverage of IconRequestHandler (60 statements) and very little automated test coverage of PublishBuildStatusAction (48 statements) and very little automated test coverage of BuildParameterResolverExtension (45 statements) . I'd start with one of those two.

          Shreya added a comment -

          is this issue available for me to take up? I'd like to start working on it

          Shreya added a comment - is this issue available for me to take up? I'd like to start working on it

          Vandit Singh added a comment -

          I'm working on it

          Vandit Singh added a comment - I'm working on it

          Mark Waite added a comment - - edited

          yashre_bh you could improve the test coverage of one of the other plugins that I maintain. No Jira issue for them, but the same instructions can be applied to:

          If you prefer to use a Jira ticket as the starting point, you could copy the description from this Jira ticket, create a new Jira ticket for one of those plugins, and assign it to yourself.

          There are two tickets that someone said they wanted to improve but then didn't improve:

          You can work on those as well.

          Mark Waite added a comment - - edited yashre_bh you could improve the test coverage of one of the other plugins that I maintain. No Jira issue for them, but the same instructions can be applied to: https://ci.jenkins.io/job/Plugins/job/schedule-build-plugin/job/master/lastSuccessfulBuild/coverage/ https://ci.jenkins.io/job/Plugins/job/versioncolumn-plugin/job/master/lastSuccessfulBuild/coverage/ https://ci.jenkins.io/job/Plugins/job/xshell-plugin/job/master/lastSuccessfulBuild/coverage/ https://ci.jenkins.io/job/Plugins/job/implied-labels-plugin/job/master/lastSuccessfulBuild/coverage/ https://ci.jenkins.io/job/Plugins/job/elastic-axis-plugin/job/master/lastSuccessfulBuild/coverage/ If you prefer to use a Jira ticket as the starting point, you could copy the description from this Jira ticket, create a new Jira ticket for one of those plugins, and assign it to yourself. There are two tickets that someone said they wanted to improve but then didn't improve: JENKINS-69756 JENKINS-69757 You can work on those as well.

          Vandit Singh added a comment -

          markewaite I'm writing test for PublicBuildStatusAction.java in Embeddable Build Status Plugin. I'm having some doubts regarding that Creating test stubs for all the methods would be correct or should i only create test stubs for methods which provide most of the functionality?
          Thanks for your time

          Vandit Singh added a comment - markewaite I'm writing test for PublicBuildStatusAction.java in Embeddable Build Status Plugin . I'm having some doubts regarding that Creating test stubs for all the methods would be correct or should i only create test stubs for methods which provide most of the functionality? Thanks for your time

          Mark Waite added a comment -

          I only create test stubs for those methods that I intend to test. I prefer tests for every public method, no matter how simple that public method is. Tests of simple public methods run very quickly and cause very little distraction in reading the tests. Absence of tests of public methods requires more thought when I'm looking at the coverage report. I try to avoid that extra thought process by writing tests for every public method.

          You're encouraged to keep pull requests small. It is great to provide a pull request that tests a single public method. If you're already confident in JUnit testing, it is also OK if a pull request includes multiple tests.

          Mark Waite added a comment - I only create test stubs for those methods that I intend to test. I prefer tests for every public method, no matter how simple that public method is. Tests of simple public methods run very quickly and cause very little distraction in reading the tests. Absence of tests of public methods requires more thought when I'm looking at the coverage report. I try to avoid that extra thought process by writing tests for every public method. You're encouraged to keep pull requests small. It is great to provide a pull request that tests a single public method. If you're already confident in JUnit testing, it is also OK if a pull request includes multiple tests.

          Vandit Singh added a comment -

          I have created this Pull request adding tests for PublicBuildStatusAction

          Vandit Singh added a comment - I have created this Pull request adding tests for PublicBuildStatusAction
          Vandit Singh made changes -
          Remote Link New: This issue links to "PR #163 (Web Link)" [ 28479 ]

            life_fire1 Aleksey
            markewaite Mark Waite
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: