通常认为单元测试不应该依赖于测试顺序。我认为这不是一个确切的规则，而是建议。
但在某些情况下，它看起来不太好。例如，我有CUtility类和CSoket，它使用CUtility方法。我想在单个单元测试执行中运行测试。因此，逻辑上首先运行CUtility测试，然后运行CSoket测试。
但单元测试的最佳实践表明：不要依赖测试订单。 为什么呢？
答案 0 :(得分：3)
因为单元测试旨在单独测试各个工作单元。 CSoket中的Cutility方法调用应该在CSoket的单元测试中进行模拟。这样，CSoket的单元测试变得独立于通过或失败的CUtility测试。然后，如果首先运行CUtility或CSoket测试，则不再重要。
答案 1 :(得分：0)
使测试彼此独立当然不是法律，而是一种好习惯。这意味着，遵循此规则将避免许多问题。但是，这可能需要付出一定的代价，即创建测试套件需要付出额外的努力。这个价格是否太高取决于您的具体情况-您必须自己判断。为了能够正确地判断它，您应该知道通过使测试彼此独立来避免哪些问题：
1）可以轻松完成对测试套件的某些修改：您可以在任何位置添加测试，删除测试，重新排序测试。如果测试相互依赖，那么任何此类步骤都可能导致您的测试套件意外失败。
2）您可以单独改进测试，而不必考虑对其他测试的影响。例如，如果您确定可以通过更简单的设置来实现某个测试的目标，则可以在本地进行更改，而不必检查所做的更改是否还会影响其他测试用例。
3）了解测试套件要简单得多：无需了解其他测试就可以理解每个测试。而且，如果测试失败，则更容易找到失败的原因，因为您也不必了解测试执行的顺序。
4）独立测试分别成功或失败，在测试失败的情况下为您提供更好的反馈。相比之下，对于依赖测试，您会产生连锁效应：如果链中的一个测试碰巧失败，通常会导致随后的测试也因为依赖而失败。
5）您可以有选择地执行测试，例如，以节省执行测试用例的时间。如果测试相互依赖，那么您要么别无选择，要么全部执行它们，或者至少分析需要哪些测试和不需要哪些测试更加复杂。
但是，正如开头所说，在考虑所有因素的情况下，依赖测试是更好的选择。在单元测试中这种情况可能很少见，但在系统测试级别上经常会发生：将系统（即设备）置于特定状态可能是一项极其昂贵的操作，例如，如果仅启动会花费大量时间。 >