如何测试JavaScript缩减输出
我们最近升级到了一个较新版本的JavaScript精简库。
在测试团队进行了大量的质量保证工作后，我们发现我们的minifier的新版本有一个问题，改变了代码块背后的意图和含义。
(生活教训:不要升级JS微型计算机，除非您确信需要新版本。)
minifier用于客户端JavaScript代码，重点放在与DOM相关的活动上，而不是更多的“业务逻辑”。
一个简化的示例说明了minifier升级所破坏的内容：
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交互(数据输入等)，如果没有用户测试(非自动化)就很难进行彻底的测试。我们曾考虑过使用像Esprima这样的JS to AST库，但考虑到可以对精简的代码进行更改的性质，它会产生太多的误报。
我们还考虑过尝试编写代表性测试，但这似乎是一项永无止境的任务(而且很可能会错过案例)。
仅供参考:这是一个非常复杂的web应用程序，有几十万行JavaScript代码。
我们正在寻找一种方法来测试最小化过程，而不是“只需再次、彻底、重复地测试所有东西”。我们希望在这个过程中应用更多的严格性/科学性。
理想情况下，如果我们有更好的科学测试方法，我们可以尝试多个微型器，而不必担心每个微型器都会以新的微妙方式破坏我们的代码。
更新：
我们的一个想法是：
- 与旧的version
- beautify it
- 缩小与新版本，
- 美化和
- 视觉上的不同。
这看起来确实是一个好主意，但是差异是如此普遍，以至于diff工具几乎标记了每一行都是不同的。
回答 6
Stack Overflow用户
发布于 2013-02-14 00:51:06
您是否考虑过单元测试框架，例如QUnitjs？编写单元测试会有相当大的工作量，但最终您将拥有一个可重复的测试过程。
Stack Overflow用户
发布于 2013-02-23 04:16:01
在我看来，您需要开始在CI (持续集成环境)中使用自动化的单元测试。QUnit已经被抛来抛去，但实际上QUnit是一个相当弱的测试系统，它的断言至少是最基本的(它甚至没有真正使用好的基于断言的语法)。它只能略微符合TDD的要求，而且也不能很好地处理BDD。
就我个人而言，我推荐使用JsTestDriver的Jasmine (它可以使用其他UT框架，也可以使用它自己的框架，而且非常fast...though，它有一些稳定性问题，我真的希望他们能修复这些问题)，并设置单元测试，可以通过多次比较来检查最小化过程。
一些比较可能需要这样做：
BDD原始代码&它的功能表现为对精简代码的expected
- compared (这就是
- 的用武之地，期望在精简代码中获得相同的功能性能/结果)
- 我甚至会更进一步(取决于您的精简方法)，并进行一个测试，然后美化精简并进行另一次比较(这会使您的测试更健壮，更有效)。
这就是为什么你可能会从像Jasmine这样的支持BDD的框架中受益的原因，而不仅仅是纯粹的TDD (啊，你发现视觉差异的结果很糟糕)，因为你正在测试行为和比较以及功能/行为的先验/后继状态，而不仅仅是测试a是否为true，并且在解析后仍然为true。
设置这些单元测试可能需要一段时间，但这是一种迭代的方法，使用大量的单元来快速和早期地将测试扩展到所有东西(我总是设置我的团队的方式是，从这一点开始的任何事情都不被认为是完整的和RC的，除非它具有没有单元测试的旧的单元Tests...anything，并且必须在接触时更新/触摸/维护单元测试，这样你就可以以一种更容易管理和更符合逻辑的方式不断改进和缩小未测试代码的数量，同时增加代码覆盖率)。
一旦您在CI中启动并运行了单元测试，您就可以将它们绑定到您的构建过程中:没有单元测试的失败构建，或者当单元测试失败时发出警报，主动监视每次签入等。使用JSDoc3自动生成文档，等等。
您正在描述的问题是构建CI和单元测试的目的，更具体地说，在您的案例中，该方法将codebase...the大小的影响降至最低，而不是使其更加复杂，而只是使整个测试的持续时间更长。
然后，把它和JSDoc3结合起来，你的风格就比90%的前端商店都要好。在这一点上，它令人难以置信的健壮和对工程师有用，并且它变得自我延续。
我真的可以继续讨论这个话题，你如何处理它，让一个团队团结起来支持它，让它自我形成和自我延续，有很多细微的差别，最重要的是从概念层面编写可测试的code...but……编写单元测试并使其自动化。一直都是。
很长一段时间以来，前端开发人员一直是半途而废的开发，没有应用实际的工程严格性和纪律。随着前端变得越来越强大和热门，这种情况必须改变，而且正在改变。针对前端/RIA应用程序的经过良好测试、覆盖良好的自动化测试和持续集成的概念是这种变化的巨大需求之一。
Stack Overflow用户
发布于 2013-02-14 00:50:16
你可以看看像Selenium Web Driver这样的东西，它允许你在不同的环境中自动测试web应用程序。有一些云托管的VM解决方案可以进行多环境测试，所以当它在Webkit中工作而不是在IE中工作时，您不会被发现。
https://stackoverflow.com/questions/14841304
复制相似问题