use*_*418 1 unit-testing code-coverage
我们公司正在努力通过在自动化单元测试中实施最小功能覆盖来提高软件质量.这已经是一个很好的起点,至少可以编写一些测试并使其自动化(尽管最好选择分支或决策).
我主要担心的是在本政策投入使用后将要编写的测试结果.我经常看到这样的规则导致大量的空测试(即没有任何断言)或一些维护噩梦的集成测试.我发现以下SO问题接近主题,但这些问题更多地集中在覆盖百分比上:
相反,我想得到帮助或洞察,我们如何避免可怕的测试质量.所以这里有几个最糟糕的单元测试no-nos以及我已经想到的避免它们的内容:
1)空测试
2)集成测试
有很多团队,我并不完全相信团队内部的评论在所有情况下都足够了.因此,我对自动化质量保证的方式更感兴趣.
TIA,lutku
我已经完成了这项工作,帮助将公司的自动化测试从散点图/补丁变为高质量的大部分用途.
我发现尝试应用指标作为质量的主要驱动因素忽略了这一点.首先,这是一个人的问题.你无法让某人毫无理由地相信某些东西,就像你没有支持就无法神奇地让他们擅长某种东西.
简短而困难的答案是,为了提高测试质量,您需要将测试代码视为一等公民.人们不会在自动化测试方面做得很好,除非他们可以在其上出售并获得提高技能的支持.很多人围绕这个问题,但事实是自动化测试很难做得很好,很多开发人员都不会"理解"或接受它是一种学习的技能; 更糟糕的是,许多人会默默地挣扎,拒绝寻求帮助.
未能证明其好处导致测试乏善可陈,这些测试反馈给开发人员,使他们认为测试没用,并且没有发现错误.如果开发人员将测试视为一件苦差事并将其打入电话,那么他们已经处于一种无用的心态 - 它变成了一种自我实现的预言和彻底的苦差事.我从经验中知道,除了编写代码然后编写所有测试以达到神奇的覆盖目标之外,几乎没有什么比这更糟的了.到那个时候,不仅代码不可测试,而且它类似于在周日晚上完成你所有的学校作业 - 这没什么好玩的.
您需要建立对单元测试可以提供帮助的原因的认识,以及良好/正确/可理解/可维护/等等.单元测试看起来像.您可以通过教育,演示,结对编程,代码审查等来实现这一目标.如果您只是设置一个硬限制并告诉人们您希望他们满足它,他们可能会反感它然后游戏系统.注意:这不是一件容易的事!让可疑开发人员看到其中的价值并开始编写非疯狂测试需要花费大量时间.没有单一的"啊哈"时刻你可以依靠.已经进行的研究表明,自动化测试可以成为一种有价值的开发工具,但很多开发人员都是教条主义者.有些人永远不会想到这个想法.
我发现结对编程工作得很好.找到一个可以轻松测试的隔离组件,或者用它们编写一些测试.完成编写测试的过程,使它们通过,重构测试和生产代码,以消除问题并使其更具可读性.随着时间的推移,建立他们的技能,向他们展示测试工具箱中最常用的技术.随着时间的推移,尝试各种技术,例如使用良好的命名实践,命名的consts,工厂方法,测试数据构建器,BDD样式"fixture作为上下文".通过在修复错误之前编写失败的测试,向他们展示如何证明存在错误.强调创造良好测试的最重要原则!
最终目标应该是所有代码团队都会就一些经验法则达成一致,例如"要注销,所有故事都必须经过充分测试并通过代码审查".如果自动化测试对于100%罚款的特定工作(例如原型)没有价值/可行性,但它应该是例外,而不是规则.
拥有尊重的代码领导者将与他们的团队合作以实现这一目标至关重要.如果您无法从所有潜在客户那里购买,那么您就遇到了一个重大问题.
您可以使用NDepend(或您选择的语言的变体)等代码指标工具来扩充您的方法,这些工具提供的功能包括列出没有良好测试覆盖率的最复杂/最常用的代码,或者缺少覆盖范围最大的区域签到之间.
祝好运.
| 归档时间： |
|
| 查看次数： |
1272 次 |
| 最近记录： |