加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

单元测试与测试之间的依赖关系

发布时间:2020-12-14 04:30:47 所属栏目:百科 来源:网络整理
导读:当你有单元测试的时候你怎么做? 一些一般单位测试 更复杂的测试检查边缘情况,具体取决于一般情况 举个例子,想象一下测试一个CSV阅读器(我刚刚做了一个示意图符号), def test_readCsv(): ...@dependsOn(test_readCsv)def test_readCsv_duplicateColumnNam
当你有单元测试的时候你怎么做?

>一些一般单位测试
>更复杂的测试检查边缘情况,具体取决于一般情况

举个例子,想象一下测试一个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() {
   ...
}
就个人而言,我不用担心在单元测试之间创建依赖关系。这听起来好像有点像我的味道一样。几点:

>如果测试失败,让其他人不能很好地了解不利条例变更所产生的问题的规模。>测试失败应该是例外而不是规范,所以为什么在绝大多数时间(希望!)没有获益的时候,浪费努力和创造依赖?如果故障经常发生,您的问题不在于单元测试依赖关系,而且频繁的测试失败。单元测试应该运行得很快。如果运行缓慢,那么您应该努力提高这些测试的速度,而不是防止后续故障。通过将代码解耦更多并使用依赖注入或嘲笑来执行此操作。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读