unit-testing - 处理 TDD/单元测试疲劳

Question

所以我已经习惯了 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

Answer 1

当然，上述“测试”在许多方面都是过大的。它太长太复杂，几乎不可读，并且断言太多东西。我很难想象这是如何从 TDD 过程中出现的。你厌倦这样的事情并不奇怪......

测试驱动的开发意味着:您应该逐步进行，其中每一步都是一个单独的测试，只断言一件事，并且绝对不包含任何逻辑(即没有 for 、 if/else 或类似的......)。所以上面的代码会产生大约 4-6 个单独的测试方法，然后你将一一实现。首先断言正确的属性初始化(根据需要使用不同的值)，然后确保方法按预期工作，依此类推...

代码覆盖率指标不会告诉您有关测试的任何信息，只是它可以向您显示根本没有被任何测试触及的生产代码。尤其是它不会告诉您触摸的代码是否真的经过测试(而不仅仅是触摸......)。这仅取决于您的测试质量。所以不要把代码覆盖率看得太重，在很多情况下，较低的覆盖率和更好的测试是更可取的......

总共:
对几乎所有内容(100% 覆盖率)进行测试并不过分，但是像您的示例中那样进行测试肯定是一个问题。

我建议您查看您的 TDD/单元测试实践，The Art Of Unit Testing书可能是一个很好的资源...

哼!
托马斯