Question

现在我已经阅读/相信元编程单元测试是一种反模式。毕竟，测试应该是DAMP而不是干嘛？所以转换：

it('successfully does x', function() {
    assert(foo.x());
});
it('successfully does y' // ...
it('successfully does z',// ...

为：

var types = ['x', 'y', 'z'];
for (var i = 0; i < types.length; i++) {
    var type = types[i];
    it('successfully does ' + type, function() {
        assert(foo[type]());
    });
}

应该是个坏主意......对吧？

问题是，我最近有一个初级程序员用这种元编程方式编写一些单元测试，我无法解释为什么这些测试存在问题。

通常我会解释说很难说元编程测试究竟是什么失败了......但是在这个程序员的测试中它非常明显，因为它们每次都会修改测试标签（即它说“成功做了x “，所以你确切地知道发生了什么。”

我还要解释一下，它会使测试代码本身变得混乱......但是很难说一个简单的foo[type]语句比多次重复测试的全部内容更加混乱。

所以，我的问题分为两部分：

元编程测试总是不好的做法吗？
如果没有，那么什么标准决定了测试的元编程是否正常？它只是“只要测试代码和输出清晰就可以了”，还是需要考虑的其他标准？

P.S。请理解我是根据既定的单元测试最佳实践（我认为这是一个合法的SO问题）要求答案，而不是主观意见（这是不合法的）。

为什么（或者是）元编程不利于单元测试

0 个答案: