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 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

          Subhojit added a comment -

          Is it still available? As I can see line coverages are still required.

          Subhojit added a comment - Is it still available? As I can see line coverages are still required.

          Mark Waite added a comment - - edited

          Is it still available? As I can see line coverages are still required.

          Yes, there are plenty of areas in the plugin that still need to increase their test coverage. Pull requests are welcomed.

          Mark Waite added a comment - - edited Is it still available? As I can see line coverages are still required. Yes, there are plenty of areas in the plugin that still need to increase their test coverage. Pull requests are welcomed.

          Subhojit added a comment - - edited

          Hi markewaite, can you please tell the setup for running jenkins server? As I can see for StatusImageTest o.jvnet.hudson.test.JenkinsRule#createWebServer: Running on [*http://localhost:63729/jenkins/*]

          Is there anyway to start for some other test cases? Or I am wrong.

          Let me know if I am missing anything

          Subhojit added a comment - - edited Hi markewaite , can you please tell the setup for running jenkins server? As I can see for StatusImageTest o.jvnet.hudson.test.JenkinsRule#createWebServer: Running on [*http://localhost:63729/jenkins/*] Is there anyway to start for some other test cases? Or I am wrong. Let me know if I am missing anything

          Mark Waite added a comment -

          The JenkinsRule in the existing tests can be used in new tests as well. https://javadoc.jenkins.io/component/jenkins-test-harness/org/jvnet/hudson/test/JenkinsRule.html is the Javadoc for that class.

          The JUnit Rule annotation is a great technique to add significant capabilities into a JUnit test with very few lines of code.

          Mark Waite added a comment - The JenkinsRule in the existing tests can be used in new tests as well. https://javadoc.jenkins.io/component/jenkins-test-harness/org/jvnet/hudson/test/JenkinsRule.html is the Javadoc for that class. The JUnit Rule annotation is a great technique to add significant capabilities into a JUnit test with very few lines of code.

          Subhojit added a comment -

          Thanks got it.

          Subhojit added a comment - Thanks got it.

          Subhojit added a comment -

          Subhojit added a comment - https://github.com/jenkinsci/embeddable-build-status-plugin/pull/239 Created a PR for the test.

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

              Created:
              Updated: