Hi markewaite, 

While I was looking at some test cases written in Junit 3, I can see those tests using private methods provided by a private inner class. While porting those tests, would you consider making those classes public so that GitClientTest can access it or would you like a plain copy of that particular private class? 

If there is a better option would like to hear that!

You're welcome to convert private inner classes in tests into public classes.

Hi,

I can also work on this transition process. markewaite rishabhbudhouliya 

Hi loghijiaha,

I have ported the CliGitAPIImplTest Junit 3 tests to GitClientTest.

You can work on GitAPITestCase or JGitAPIImplTest. Please mention the class here so that anyone can work on the other one. Thanks!

I will work on JGitAPIImplTest.

Thank you very much to both of you, loghijiaha and rishabhbudhouliya!

Any efficient idea you could suggest to check whether the test already implemented or not in GitClientTest ?

I'm not sure how Mark would suggest it, but here is my opinion:

1) The first obvious way would be to search for the same test-case name, for example: testRefSpecWithNullValues might be referred with a similar name in GitClientTest.
2) If the name isn't obvious then try to understand what the test is asserting and try to find the same definition.

Also, if you are using IntelliJ it automatically highlights duplicate code, so that can be also used.

loghijiaha I like the suggestion from rishabhbudhouliya to review the test names and the test assertions.

Some assertions are not immediately visible (like the assertion of expected job status in the build() calls, but assertions are a very useful way to avoid losing knowledge in the transition from JUnit 3 to JUnit 4.

Great thanks. markewaite and rishabhbudhouliya I check it out. I think most of the test cases lie on GitAPITestCase. @NotImplementedInJGit annotations are helping to identify the relevant tests in my case.

markewaite loghijiaha rishabhbudhouliya I will like to work on it!!

I will do the remaining part which is GitAPITestCase!!

darkphoenix17 Great. I'd like to list some steps you can perform to do so: 

• Look at GitClientTest, GitClientCliTest, GitClientCloneTest and GitClientFetchTest to understand the JUnit 3 to 4 transition of git client test cases. You can start with any of these classes if it seems too much at first (I'll recommend GitClientTest)
• The transition involves using JUnit 4 APIs instead of JUnit 3 and avoiding the usage of `WorkingArea` (it provides the ability to create a temporary local workspace for git operations). We have tried using `WorkspaceWithRepo` to serve as a replacement for `WorkingArea`.
• Feel free to ask any questions on the [gitter channel|https://gitter.im/jenkinsci/git-plugin] for the git plugin. markewaite and I would be more than happy to help!

Sure rishabhbudhouliya

rishabhbudhouliya the link [https://gitter.im/jenkinsci/git-plugin is not working i suppose. I am stuck and need help.

Sorry, the correct link is https://gitter.im/jenkinsci/git-plugin

rishabhbudhouliya markewaite Is this issue still open for work, then may I work on some part to transition the tests from JUnit 3 to JUnit 4. I'm still new to Jenkins but hoping to learn as much I can.

ayang17 the issue is definitely still open for work. Would love to have help from others to migrate those tests from JUnit 3 to JUnit 4.

ayang17 choose any of the methods in GitAPITestCase that are public void test_.*. Fewer statements in the test method will make that method easier to convert to JUnit 4. For example, you might consider:

• test_getRemoteURL
• test_empty_comment
• test_create_branch
• test_delete_branch
• test_delete_tag
• test_list_tags_with_filter
  test_list_tags_without_filter

Sure, thanks markewaite

markewaite I implemeted the test_getRemoteURL, wanted your review about the same that my approach is okay or there is some area where I can improve, so I have created a PR, please review it.

Special thanks to ayang17 for the great progress made. Remains open because there are still tests to be converted. The progress is very much appreciated!

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?

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.

PR: https://github.com/jenkinsci/git-client-plugin/pull/814

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