如何有效地测试脚本引擎?
我一直致力于 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");
}
}
这样做将需要我编写数千个测试,这似乎又不值得。
I have been working on an ECMAScript implementation and I am currently working on polishing up the project. As a part of this, I have been writing tests like the following:
[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);
}
The problem is that there are so many points of failure in this test and similar tests that it almost doesn't seem worth it. It almost seems like my effort would be better spent reducing coupling between modules. To write a true unit test I would have to assume something like this:
[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");
}
}
Doing this would require me to write thousands of tests which once again does not seem worth it.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
只是在这里吐槽,但是如果您将测试存储在文件/数据库/等中怎么办...(正如 Doug 指出的 - 在版本控制中存储的能力使文件成为最佳选择!)每个条目都可以有一个名称、一个脚本,以及预期输出。
然后,您可以编写一个小应用程序,使用您的引擎执行每个脚本,并将输出与预期输出进行比较,并根据结果通知您成功/失败。
这不会让您免于测试脚本引擎本身的痛点,但维护这样的东西可能比为您可以设想使用脚本运行时的每种方式编写单元测试更容易。
Just spitballing here, but what if you stored your tests in a file/database/etc... (as Doug points out - the ability to store in version control makes files the best choice!) Each entry could have a Name, a Script, and the Expected Output.
Then you could just write a small app that executes each script using your engine and compares the output to the expected output, and notifies you of success/failure based on the result.
This wouldn't save you from needing to test the pain points in the script engine itself, but it might be easier to maintain something like this than to write a unit test for each way that you can envision using the scripting runtime.