I have a Map which takes in an a String key, and an array of custom objects as the value. the map usually contains two entries, and the arrays for both entries never change in terms of data; once they are populated(one, for example, is an array of 50 state objects) they do not change. I have been following the practice that all tests should be self contained, i.e. each test class should have its own data for testing to reduce dependencies and such, but i have repeated the initialisation and population of these arrays across two different test classes already, with the potential to have to do it again for another couple of test classes.

Can it be considered best practice to have this array creation moved to a separate utility class solely for testing?

  • 1
    Most (unit)test frameworks have the concept of setup and teardown code that can be shared between (related) tests. This is the place where you would populate (setup) your map. – Bart van Ingen Schenau Dec 14 '15 at 13:15

Tests are code, and as such common best practices should be applied: repeated code should probably be extracted into a method. However, this has to be balanced:

  • Tests should be very, very obvious, more so than other code. A layer of abstraction that makes it difficult to understand what a test does and why exactly it is supposed to pass, might make it unnecessarily difficult to debug a test failure.
  • Changes to the extracted initialization method affect all tests using that method, even if this is not intended. Therefore, common initialization should only be used where it is your intention that all of these tests use the same test fixture, not where this is an accidental test implementation detail.
  • If you have shared state, this makes your tests more brittle. A method that creates a fresh fixture is preferable over shared state. In particular, I'm very critical of setUp()/tearDown() methods common in some frameworks. Instead, the test fixture should be separate from the class holding the test methods, and each test case should instantiate its own fixture.
  • So for my vcase, the array initialisations would be extracted out but any manipulation of the arrays would happen in the test classes. If the array needs to differ from the shared one then it can be initialised and altered in the test or a different array can be initalised in the test instead. Would that be considered a balanced approach? – jbailie1991 Dec 14 '15 at 12:22
  • 1
    @jbailie1991: finding the right balance is up to someone who knows the code, the data and the test requirements, so in short it is up to you. Do not expect someone here to make this decision for you. – Doc Brown Dec 14 '15 at 12:29
  • @DocBrown I wasn't expecting someone to make the decision for me, I was seeking advice/guidance not hand holding – jbailie1991 Dec 16 '15 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.