单元测试 – 处理TDD /单元测试疲劳
发布时间:2020-12-13 20:09:19 所属栏目:百科 来源:网络整理
导读:所以我已经习惯了TDD,但我遇到了一个意想不到的问题:我已经厌倦了100%的代码覆盖率.编写的代码比代码本身更加繁琐,而且我不确定我是否做得对.我的问题是:你应该测试什么样的东西,以及什么样的东西是矫枉过正的? 例如,我有一个如下测试,我不确定它是否有
所以我已经习惯了TDD,但我遇到了一个意想不到的问题:我已经厌倦了100%的代码覆盖率.编写的代码比代码本身更加繁琐,而且我不确定我是否做得对.我的问题是:你应该测试什么样的东西,以及什么样的东西是矫枉过正的?
例如,我有一个如下测试,我不确定它是否有用.我该怎么办才能继续关注TDD,但又不厌倦写测试? describe 'PluginClass' describe '.init(id,type,channels,version,additionalInfo,functionSource,isStub)' it 'should return a Plugin object with correct fields' // Create test sets var testSets = new TestSets() var pluginData = { 'id' : null,'type' : null,'channels' : null,'version' : null,'additionalInfo' : null,'functionSource' : null,'isStub' : true } testSets.addSet({ 'pluginData' : pluginData }) var pluginData = { 'id' : "testPlugin1",'type' : "scanner",'channels' : ['channelA','channelB'],'version' : "1.0",'additionalInfo' : {'test' : "testing"},'functionSource' : "function () {alert('hi')}",'isStub' : false } testSets.addSet({ 'pluginData' : pluginData }) for (var t = 0; t < testSets.getSets().length; t ++) { var aTestSet = testSets.getSet(t) var plugin = new Plugin().init( aTestSet.pluginData.id,aTestSet.pluginData.type,aTestSet.pluginData.channels,aTestSet.pluginData.version,aTestSet.pluginData.additionalInfo,aTestSet.pluginData.functionSource,aTestSet.pluginData.isStub ) plugin.getID().should.eql aTestSet.pluginData.id plugin.getType().should.eql aTestSet.pluginData.type plugin.getChannels().should.eql aTestSet.pluginData.channels plugin.getVersion().should.eql aTestSet.pluginData.version plugin.getAdditionalInfo().should.eql aTestSet.pluginData.additionalInfo eval("fn = " + aTestSet.pluginData.functionSource) JSON.stringify(plugin.getFunction()).should.eql JSON.stringify(fn) plugin.getIsStub().should.eql aTestSet.pluginData.isStub } end end end
当然,上述“测试”在很多方面都是过度的.它太长而复杂,几乎不可读,并且断言太多东西.我很难想象这是如何从TDD过程中产生的.你厌倦了这样的东西就不足为奇了……
测试驱动的开发意味着:你应该进入婴儿步骤,每个步骤都是一个单独的测试,只断言一件事,并且绝对没有逻辑(即,不,如果/其他或类似的……).因此,上面的代码将导致大约4-6个单独的测试方法,然后您将逐个实现.首先断言正确的属性初始化(根据需要使用不同的值),然后确保方法按预期工作,依此类推…… 代码覆盖率指标不会告诉您有关测试的任何信息,除非它可以向您显示任何测试都未触及的生产代码.特别是它不会告诉你触摸的代码是否真的被测试(而且不仅仅是触摸……).这仅取决于测试的质量.所以不要把代码覆盖太严重,有很多情况下,更好的测试更低的覆盖率更加优先… 总共: 我建议您查看您的TDD /单元测试实践,The Art Of Unit Testing本书可能是一个很好的资源… HTH!托马斯 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
相关内容
- c# – 人们如何绕过需要不同数量的超类参数的子类init方法?
- 微信XML消息model定义之微信公众平台(一)
- Oracle数据加载和卸载的实现方法
- ajaxSubmit异步提交
- c# – 在winform文本框中自动完成[包含而不是开始]
- jffs2_scan_eraseblock(): Magic和Empty Flash at...解决办
- postgresql 修改表结构,添加索引
- 用Swift做个游戏Lecture 03 —— 实现foreground的持续移动
- ruby-on-rails – 每个铁轨项目必须有ruby宝石(2011年版)
- Access Control-Allow-Headers不允许使用Ajax请求头域