Consider unit testing a dictionary object. The first unit tests you might write are a few that simply adds items to the dictionary and check exceptions. The next test may be something like testing that the count is accurate, or that the dictionary returns a correct list of keys or values.
However, each of these later cases requires that the dictionary can first reliably add items. If the tests which add items fail, we have no idea whether our later tests fail because of what they’re testing is implemented incorrectly, or because the assumption that we can reliably add items is incorrect.
Can I declare a set of unit tests which cause a given unit test to be inconclusive if any of them fail? If not, how should I best work around this? Have I set up my unit tests wrong, that I’m running into this predicament?
It’s not as hard as it might seem. Let’s rephrase the question a bit:
Answer to the above is obvious; you don’t. You let them fail for one simple reason – your assumptions have failed, and test should fail. It’s the same here. Once you get your add tests to work, from that point on you assume add works. You shouldn’t treat your tested code any differently than 3rd party tested code. Once it’s proven to work, you assume it indeed does.
On a different note, you can utilize concept called guard assertions. In your remove test, after the arrange phase you introduce additional assert phase, which verifies your initial assumptions (in this case – that the add is working). More information about this technique can be found here.
To add an example, NUnit uses the concept above disguised under the name Theory. This does exactly what you proposed (yet it seems to be more related to data driven testing rather than general utility):
However, I think what Mark Seemann states in an answer to the question I linked makes the most sense: