Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Junit and reusable code

Options
  • 19-10-2017 9:01am
    #1
    Registered Users Posts: 5,532 ✭✭✭


    Hi folks

    Say you have 10 test cases using junit. Each test has a block of similar code (including the assertion) to go with its own specific functionality.

    Is there any reason not to refactor the code into reusable method?

    I ask as i made such a suggestion but was told "No, its a test case but i take your point".

    Thought this was a bit of a cop-out. Is there any logic behind this?


Comments

  • Registered Users Posts: 2,790 ✭✭✭John_Mc


    Hi folks

    Say you have 10 test cases using junit. Each test has a block of similar code (including the assertion) to go with its own specific functionality.

    Is there any reason not to refactor the code into reusable method?

    I ask as i made such a suggestion but was told "No, its a test case but i take your point".

    Thought this was a bit of a cop-out. Is there any logic behind this?

    I'm in the .NET world and so use NUnit but you can certainly use a base class shared by your unit tests to hold the reusable code.

    The Setup method is obviously another place for the initialisation shared by your unit tests


  • Registered Users Posts: 1,148 ✭✭✭punk_one82


    I ask as i made such a suggestion but was told "No, its a test case but i take your point".

    That's a pretty stupid response. Code can be reused in test classes as well.


  • Registered Users Posts: 11 SionnachRoe


    When writing unit tests one can, and should, use all the good design practices that would be put into the production code. Copy/Paste re-use is no more excusable in the unit tests than in the production code.

    That said, this is not really a question about good design practices, more a question about when and what to refactor.

    Refactoring starts at point X (in terms of delivered functionality/project completion) and (after an amount of time and effort) brings us to point X. It is understandable why those in charge of schedule and deadlines would prioritize feature delivery over refactoring. A given piece of refactoring may be small, but empowering developers to refactor as they see fit can slow things down a lot. Code is never finished and people can always see better ways of re-doing what others (and even they themselves) have done previously.

    It may reflect the opinions (on unit tests) of the speaker but 'No, its a test case..' is not a great response, perhaps they meant It's not broke, there's no need to fix it... at the moment, who can tell.

    A possible plan is, don't worry about the 10 existing cases up until the point that the functionality which they are testing is being changed or, a new piece of functionality in the same area is being implemented.
    At that point, add methods for the reusable code and implement the new test using them or refactor the old test to use them.
    Over time, as the functionality under test changes for each of the 'bad' tests, one can refactor them to use the shared code.


Advertisement