In a lot of unit testing frameworks, test cases are independent. For example, GoogleTest says:

Tests should be independent and repeatable. It’s a pain to debug a test that succeeds or fails as a result of other tests. googletest isolates the tests by running each of them on a different object.

I don't understand why it is good that test cases are independent. For example, assume an composite object A which uses objects B and C. It is obvious that if B and C are buggy, what A does will be incorrect too, whether it is implemented correctly or not. So I somehow like to see an output like this:

Testing B [SUCCEED]
Testing C [FAILED]
Testing A [FAILED] because dependent test C failed. 

Do these framework assume that rather than depending these to each other, it is better to test A by mocking B and C? Because sometimes writing correct mocker for your classes can be complex (and buggy itself), so I still think depending tests is better.

CodePudding user response：

You're thinking of the wrong type of (in)dependence. The dependence meant here is that a testA2 depends on some form of initialization or setup done in testA1 (which might depend on initialization done by testB2, etc.). This makes your tests very brittle, because out of order execution, or failing tests will cascade through your entire set of test cases. It also makes it impossible to run the test case in isolation.

As an example, testA1 could create records in a test database, and testA2 expects those records to be present in the test database. If testA1 fails (or hasn't been run yet), then testA2 will fail too.

If instead you have independent test cases (e.g. create the records as part of the setup of testA2), then the failure of a test to run (or run correctly), or out of order execution of tests, will not prevent your other tests from completing successfully.

Of course, if there is something fundamentally broken in a dependency between your class under test (e.g. A) and another class (e.g. C), then you might have multiple test cases failing, but that is a different dependency problem than meant in the text you quote.

With independent test cases, you can still achieve the test result you desire (tests for A fail if C is broken) if you you don't mock/stub the dependency (e.g. C) of the (direct) class under test (e.g. A)).

To be clear, not everyone likes that type of dependence, and some will strive to make their unit tests independent from this type of problem as well by mocking, stubbing, etc. That is a more opinionated practice though, as it increases complexity, could make your tests more brittle, and makes it easier to miss problems with the interaction between those classes.

However, as I said earlier, that is a different type of independence than what is generally meant (and specifically in the text you quote) with independence of test cases.