As the title suggests my question is whether or not unit-tests should be entirely self-contained or can one rely on the results yielded by previous tests?
What I mean, in case that it isn't entirely clear, is that if ones initial test sufficiently asserts that a certain module A works in a certain way can, or more appropriately, should one write subsequent tests with the assumption that the aforementioned module A is tested beforehand? This would imply that the order that the unit-tests are executed matters.
Or should each individual test be self-reliant to the point that if one needs to know whether a module B works, which can only be validated if module A works, should one then test module A within the same test as module B which would imply that the separate unit-tests can be executed in any order.
To give a concrete example, consider the "stack" datatype, which we won't delve too deeply into, specifically two fundamental properties we'd need to be able to reason about the datatype in any meaningful sense. Namely,
Empty(). Now, if one wishes to test the validity of
isEmpty which takes a stack and returns a
False depending on whether or not the stack received as an argument is empty or not one would first need to create an empty stack using
Then we consider the scenario of doing the following:
isEmpty(Empty()) and checking what kind of result we get. Either we get a
True statement, so
Empty() could have returned a non empty stack and
isEmpty might view that as an empty stack which would be wrong. Or we get
False, and we still don't know how the two actually interplay, nor how either works on their own (assuming we can't view the source). (There is a third option, we receive something that's neither
False, but that is beyond the scope of this discussion, this is solely a remark).
Finally, to tie this back to my question, if we create a test where we can be reasonably certain that
isEmpty works in a satisfying manner can then all tests executed after it trust that it does indeed work? Or should they all try and incorporate this ambiguity into their own test logic (for instance, including an else statement to if neither
False was returned)