It is a very often opinion that unit testing should not rely on tests order. I think it is not an exact rule but recommendation.
But in some cases it does not look good.
To make tests independent of each other is certainly not a law, but a good practice. That means, following this rule will avoid a number of problems. This may, however, come at a price, namely some extra effort for the creation of the test suite. Whether this price is too high depends on your specific circumstances - you will have to judge it yourself. To be able to properly judge it, you should know what kind of problems you avoid by making tests independent of each other:
1) Certain modifications of your test suite can be done without trouble: You can add tests at any place, delete tests, re-order tests. If tests are dependent on each other, any such step can cause your test suite to fail unexpectedly.
2) You can improve tests individually without having to think about impact on other tests. For example, if you figure out that the goal of a certain test can be achieved with a simpler setup, you can make that change locally without having to check whether the changes you make would also impact other test cases.
3) Understanding the test suite is much simpler: Every test can be understood without looking at other tests. And, if a test fails it is much easier to find the cause for the failure because you do not also have to understand the sequence of test executions.
4) Independent tests succeed and fail individually, giving you a better feedback in case of test failures. In contrast, with dependent tests, you have a chain-effect: If one test in the chain happens to fail, it typically follows that the subsequent tests also fail just because of the dependency.
5) You can execute your tests selectively, for example to save time during test case execution. If tests are dependent on each other, you may either not have any choice rather than to execute them all, or at least the analysis which tests you need and which are not needed is more complex.
But, as said at the beginning, there are also situations where dependent tests are a better choice, taking everything into account. It may be rare in unit-testing, but on system testing level it happens often: Bringing a system (i.e. a device) into a certain state can be an extremely expensive operation, for example if the booting alone takes a significant time.
Because unit tests are meant to test individual units of work in isolation. Cutility method calls in CSoket should be mocked in unit tests for CSoket. This way, the unit tests for CSoket become independent of CUtility tests passing or failing. Then, it no longer matters if CUtility or CSoket tests are run first.