This question already has an answer here:
How do you manage the dependency of one unit test on another unit test succeeding?
So, supposed I have a class and this class has say 5 methods. I create like 2 dozen unit tests (test methods) for that class. each unit tests tests something specific and unique - so nothing is tested twice.
So for instance I have a couple of unit test that checks if the class' constructor is working properly. Maybe testing that the constructor does not throw any exceptions and that the appropriate exception is thrown when no (valid) parameters are passed.
Other unit tests may also use the constructor (in the setup stage of the unit test) but non perform any checks on them because there is another unit test that has that job.
Now I start to refactor this class and I break some of the unit tests.
I click open one test and it is a specific edge-case test that is pretty elaborate. Hard to see what is going wrong and why. If I would have opened the constructor test first, I would have seen that THAT was the problem. So I wasted my time. Granted, in one unit test file it is a trivial example but in a large test suite where success-dependencies may span across file boundaries it gets complex.
So my question is first: is this way of unit testing correct - most effecient (not testing the same thing multiple times)?
The next question is: How do you manage these success-dependencies between unit tests and how do you make sure you can pinpoint the test case that displays the 'real' problem (by failing).