经过测试团队的大量质量保证工作后,发现我们的缩小器的新版本存在问题,会改变一段代码块的意图和含义。
(生活教训:除非你确信需要新版本,否则不要升级JS缩小器。)
该缩小器用于客户端JavaScript代码,重点是DOM相关的活动,而不是“业务逻辑”。
以下是被缩小器升级破坏的简化示例:
function process(count)
{
var value = "";
value += count; //1. Two consecutive += statements
value += count;
count++; //2. Some other statement
return value; //3. Return
}
被错误压缩成以下内容:
function process(n){var t="";return t+n+n,n++,t}
虽然我们可以编写一些单元测试来捕捉一些潜在问题,但是考虑到JavaScript与DOM交互(数据输入等)的重要性,如果没有用户测试(非自动化),很难进行全面测试。我们曾考虑使用JS to AST库(如Esprima),但考虑到可能对缩小代码进行的更改的性质,它将产生太多错误的结果。
我们还考虑尝试编写代表性测试,但这似乎是一项永无止境的任务(且可能会错过某些情况)。
提示:这是一个非常复杂的Web应用程序,有数十万行JavaScript代码。
我们正在寻找一种测试缩小过程的方法,而不是“只是再次彻底测试并重复”。我们希望为该过程应用更多的严谨/科学方法。
理想情况下,如果我们有更好的科学方法来测试,我们可以尝试多个缩小器,而不必担心每个缩小器都会以新的微妙方式破坏我们的代码。
更新:
我们有一个想法:
- 使用旧版本进行缩小
- 美化
- 使用新版本进行缩小
- 美化
- 进行可视化比较
这似乎是个好主意,但差异非常普遍,差异工具标记了几乎每一行都不同。