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

Convert git client plugin tests from JUnit 3 to JUnit 4

    XMLWordPrintable

Details

    Description

      The git client plugin tests have started their transition process to retire the JUnit 3 based GitAPITestCase, CliGitAPIImplTest, and JGitAPIImplTest. They should be replaced by the parameterized GitClientTest.

      For each test in GitAPITestCase, CliGitAPIImplTest, and JGitAPIImplTest:

      • If it is already tested in GitClientTest, delete the test from the JUnit 3 based tests
      • If it is not already tested in GitClientTest, write a test in GitClientTest or in a new test class and delete the test from the JUnit 3 based tests

      This issue could be worked by multiple people concurrently, so long as they coordinate with one another on the specific tests they are converting.

      Attachments

        Activity

          Have gone through the test methods in GitAPITestCase that are to be transformed into JUnit 4 and noticed some of them can not be migrated to GitClientTest because they consume some abstract methods and new host test class is not abstract. Thoughtfully I see two approaches to solve the issue. 1. We can have GitClientTest converted into an abstract class but this comes with a cost for those classes that extends the class. 2. We can create a new test class to handle these test methods. 

          markewaite let me know what you think?

          kdaud Daud Kakumirizi added a comment - Have gone through the test methods in GitAPITestCase that are to be transformed into JUnit 4 and noticed some of them can not be migrated to GitClientTest because they consume some abstract methods and new host test class is not abstract. Thoughtfully I see two approaches to solve the issue. 1. We can have GitClientTest converted into an abstract class but this comes with a cost for those classes that extends the class. 2. We can create a new test class to handle these test methods.  markewaite  let me know what you think?
          markewaite Mark Waite added a comment -

          I see two approaches to solve the issue. 1. We can have GitClientTest converted into an abstract class but this comes with a cost for those classes that extends the class. 2. We can create a new test class to handle these test methods.

          I prefer a new test class. Large test classes tend to become unwieldy.

          markewaite Mark Waite added a comment - I see two approaches to solve the issue. 1. We can have GitClientTest converted into an abstract class but this comes with a cost for those classes that extends the class. 2. We can create a new test class to handle these test methods. I prefer a new test class. Large test classes tend to become unwieldy.
          kdaud Daud Kakumirizi added a comment - PR:  https://github.com/jenkinsci/git-client-plugin/pull/814
          hrushi20 Hrushi20 added a comment - - edited

          markewaite, When I try to migrate the GitAPITestCase to junit 4, it is an abstract class. I feel it's better to update the GitAPITestCase to junit 4 in the same class rather than move the tests to GitClientTest as GitClientTest has grown very big and can be difficult to maintain. We can update the internal behaviour of GitAPITestCase to Junit 4 and test it using the extended class i.e(JGitApacheAPIImplTest,CliGitAPIImplTest). What do you think about this?

          Thank You.

           

          hrushi20 Hrushi20 added a comment - - edited markewaite , When I try to migrate the GitAPITestCase to junit 4, it is an abstract class. I feel it's better to update the GitAPITestCase to junit 4 in the same class rather than move the tests to GitClientTest as GitClientTest has grown very big and can be difficult to maintain. We can update the internal behaviour of GitAPITestCase to Junit 4 and test it using the extended class i.e(JGitApacheAPIImplTest,CliGitAPIImplTest). What do you think about this? Thank You.  
          markewaite Mark Waite added a comment -

          hrushi20 I believe that the technique you're describing was attempted by kdaud. I would advise against the technique because it is attempting to make a single very large change to that file of tests. I've generally had better results by making a series of small changes. Each of the small changes helps me learn, understand, and better prepare for the later steps.

          If there are too many tests in GitClientTest, then the converted tests can be placed in other classes. The transition is not limited to converting tests from the existing class to a single destination class. They can be converted from their existing single class into many different classes, grouped by the capabilities being tested or by other useful attributes.

          markewaite Mark Waite added a comment - hrushi20 I believe that the technique you're describing was attempted by kdaud . I would advise against the technique because it is attempting to make a single very large change to that file of tests. I've generally had better results by making a series of small changes. Each of the small changes helps me learn, understand, and better prepare for the later steps. If there are too many tests in GitClientTest, then the converted tests can be placed in other classes. The transition is not limited to converting tests from the existing class to a single destination class. They can be converted from their existing single class into many different classes, grouped by the capabilities being tested or by other useful attributes.

          People

            hrushi20 Hrushi20
            markewaite Mark Waite
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: