Question

我一直致力于ECMAScript实施，目前正在努力完善该项目。作为其中的一部分，我一直在编写如下测试：

[TestMethod]
public void ArrayReduceTest()
{
    var engine = new Engine();
    var request = new ExecScriptRequest(@"
        var a = [1, 2, 3, 4, 5];
        a.reduce(function(p, c, i, o) {
            return p + c;
        });
    ");
    var response = (ExecScriptResponse)engine.PostWithReply(request);
    Assert.AreEqual((double)response.Data, 15D);
}

问题是在这个测试和类似的测试中有很多失败点，它几乎看起来不值得。看起来我的努力似乎更好地用于减少模块之间的耦合。要编写真正的单元测试，我必须假设这样的事情：

[TestMethod]
public void CommentTest()
{
    const string toParse = "/*First Line\r\nSecond Line*/";
    var analyzer = new LexicalAnalyzer(toParse);
    {
        Assert.IsInstanceOfType(analyzer.Next(), typeof(MultiLineComment));
        Assert.AreEqual(analyzer.Current.Value, "First Line\r\nSecond Line");
    }
}

这样做需要我编写成千上万的测试，再一次看起来不值得。

Answer 1

这里只是spitballing，但如果你将你的测试存储在一个文件/数据库/等等......（正如Doug指出的那样 - 在版本控制中存储的能力使文件成为最佳选择！）每个条目都可以有一个名称，脚本和预期输出。

然后你可以编写一个小应用程序，使用你的引擎执行每个脚本，并将输出与预期输出进行比较，并根据结果通知你成功/失败。

这不会让您无需测试脚本引擎本身的痛点，但维护此类内容可能比为使用脚本运行时设想的每种方式编写单元测试更容易。

如何有效地测试脚本引擎？

1 个答案: