Every so often some engineer has the bright idea of introducing a way to express dependencies between test cases, for example in the Bash test framework, usually with the objective of optimising a test run and/or saving developer time in the code-build-test cycle.
This is almost always a BAD IDEA for the following reasons:
The problem of developer time can be tackled as follows (using the Bash test framework as an example):
Sometimes the motivation to introduce test case dependencies arises from a slow and stateful System Under Test (SUT). If the final state of a (passed) costly test serves as the fixture for another test, and there is no faster way to create the fixture, then a dependency from the first to the second is an obvious way to save time when running both. But this is a false saving.
The slow & stateful SUT problem is better tackled by combining all the dependent tests into a single test case. A single, gigantic test case is hard to understand and costly to run, but a set of small, interdependent test cases is even harder to understand and maintain, and just as costly, and gives the false impression that they can be run independently. If you need to be run only the first step of the test case during development, then create a temporary test case consisting of only the first step, by copying and pasting (or better, factoring the common code into a shared function) and use that, discarding once no longer needed.