当你有单元测试的时候你怎么做？
>一些一般单位测试
>更复杂的测试检查边缘情况，具体取决于一般情况
举个例子，想象一下测试一个CSV阅读器(我刚刚做了一个示意图符号)，
def test_readCsv(): ... @dependsOn(test_readCsv) def test_readCsv_duplicateColumnName(): ... @dependsOn(test_readCsv) def test_readCsv_unicodeColumnName(): ...
我预计子测试只有在他们的父测试成功时才能运行。原因在于运行这些测试需要时间。许多失败的报告，回到一个单一的原因，也不会提供信息。当然，我可以把所有的边缘案例放在主要的测试中，但是我想知道是否有更有条理的方法来做到这一点。
我发现这些相关但不同的问题，
> How to structure unit tests that have dependencies?
> Unit Testing – Is it bad form to have unit test calling other unit tests
更新：
我发现了TestNG，它具有很好的内置支持测试依赖性。你可以写这样的测试，
@Test{dependsOnMethods = ("test_readCsv"))
public void test_readCsv_duplicateColumnName() {
...
}
就个人而言，我不用担心在单元测试之间创建依赖关系。这听起来好像有点像我的味道一样。几点：
>如果测试失败，让其他人不能很好地了解不利条例变更所产生的问题的规模。>测试失败应该是例外而不是规范，所以为什么在绝大多数时间(希望！)没有获益的时候，浪费努力和创造依赖？如果故障经常发生，您的问题不在于单元测试依赖关系，而且频繁的测试失败。单元测试应该运行得很快。如果运行缓慢，那么您应该努力提高这些测试的速度，而不是防止后续故障。通过将代码解耦更多并使用依赖注入或嘲笑来执行此操作。
