Is it a good way of unit testing to use another, tested function to make preparations for the actual test?

In a perfect world, every unit test can only be broken in single way. Every unit test “lives” in isolation to every other. Your addNewFruit test can be broken by breaking isInFruitsList – but luckily, this isn’t a perfect world either.

Since you already tested isInFruitsList method, you shouldn’t worry about that. That’s like using 3rd party API – it (usually) is tested, and you assume it works. In your case, you assume isInFruitsList works because, well – you tested it.

Going around the “broken in a single way” you could try to expose underlying fruits list internally (and use InternalsVisibleTo attribute), or passing it via dependency injection. Question is – is it worth the effort? What do you really gain? In such simple case, you usually gain very little and overhead of introducing such constructs usually is not worth the time.

Leave a Comment