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.