如何测试JavaScript缩小输出 [英] How to test JavaScript minification output
问题描述
我们最近升级到了JavaScript缩小库的较新版本.
We recently upgraded to a newer build of a JavaScript minification library.
在测试团队进行了大量质量保证工作之后，发现我们的缩小器的新版本存在一个问题，该问题改变了代码块背后的意图和含义.
After a significant amount of quality assurance work by the testing team, it was discovered that the new version of our minifier had an issue that changed the intention and meaning behind a block of code.
(生活课:除非您真的确信需要新版本，否则不要升级JS缩小程序.)
(Life lesson: don't upgrade JS minifiers unless you are really convinced you need the new version.)
minifier用于客户端JavaScript代码，重点放在与DOM相关的活动上，而不是几乎没有业务逻辑"那么多.
The minifier is used for client side JavaScript code with a heavy emphasis on DOM related activity, not nearly as much "business logic".
简化程序的简化示例:
function process(count)
{
var value = "";
value += count; //1. Two consecutive += statements
value += count;
count++; //2. Some other statement
return value; //3. Return
}
错误地缩小为以下内容:
Was minified incorrectly to the following:
function process(n){var t="";return t+n+n,n++,t}
尽管我们可以编写一些单元测试来潜在地解决某些问题，但是鉴于JavaScript大量涉及DOM交互(数据输入等)，但是如果没有用户测试(非自动化)很难进行彻底的测试.我们曾考虑使用像Esprima这样的JS到AST库的JS，但是考虑到可以对缩小的代码进行更改的性质，它将产生太多的误报.
While we could write some unit tests to catch some of the issues potentially, given that the JavaScript is heavy on DOM interactions (data input, etc.), it's very difficult to test thoroughly without user testing (non-automated). We'd pondered using a JS to AST library like Esprima, but given the nature of the changes that could be done to the minified code, it would produce far too many false positives.
我们还考虑过尝试编写具有代表性的测试，但这似乎是一项永无止境的任务(并且很可能会遗漏案例).
We also considered trying to write representative tests, but that seems like a never-ending task (and likely to miss cases).
仅供参考:这是一个非常复杂的Web应用程序，包含数十万行JavaScript代码.
FYI: This is a very sophisticated web application with several hundred thousand lines of JavaScript code.
我们正在寻找一种测试缩小过程的方法，而不仅仅是对所有内容进行彻底，彻底和重复的测试".我们想对此过程应用更多的严格性/科学性.
We're looking for a methodology for testing the minification process short of "just test everything again, thoroughly, and repeat." We'd like to apply a bit more rigor/science to the process.
理想情况下，如果我们有更好的科学测试方法，我们可以尝试使用多个压缩器，而不必担心每个破坏器都会以新的微妙方式破坏代码.
Ideally, we could try multiple minifiers without fear of each breaking our code in new subtle ways if we had a better scientific method for testing.
更新:
我们的一个主意是:
- 使用旧版本缩小尺寸
- 美化它
- 使用新版本缩小
- 美化，然后
- 视觉上的差异.
看起来确实是个好主意，但是差异如此普遍，以至于diff工具将几乎每一行都标记为不同.
It did seem like a good idea, however the differences were so common that the diff tool flagged nearly every line as being different.
推荐答案
听起来像我，您需要开始在CI(连续集成环境)中使用自动化的单元测试.QUnit早已被抛弃，但实际上QUnit是一个相当弱的测试系统，其断言至少是准系统(它甚至没有真正使用基于断言的良好语法).它仅勉强合格为TDD，也不能很好地处理BDD.
Sounds to me like you need to start using automated Unit Tests within your CI (continuous integration environment). QUnit has been thrown around, but really QUnit is a pretty weak testing system, and its assertions are barebones at the minimum (it doesn't even really use a good assertion-based syntax). It only marginally qualifies as TDD and doesn't handle BDD very well either.
我个人建议将茉莉花与
Personally I'd recommend Jasmine with JsTestDriver (it can use other UT frameworks, or its own, and is incredibly fast...though it has some stability issues that I really wish they'd fix), and setup unit tests that can check minification processes by multiple comparisons.
可能需要进行一些比较:
Some comparisons would likely need to be:
- 原始代码&其功能符合预期
- 与精简代码相比(这是BDD的所在，期望精简代码具有相同的功能性能/结果)
- 我什至会更进一步(取决于您的缩小方法)，然后进行测试，以美化缩小并进行另一个比较(这使您的测试更可靠且更有效).
这些类型的测试是为什么您可能会从Jasmine之类的具有BDD功能的框架中受益的原因，而不仅仅是纯粹的TDD(也就是您发现视觉差异的结果很烂)，因为您正在测试行为以及功能/行为的比较和先前/后状态，不仅是a为true，而且在解析后仍然为true.
These kinds of tests are why you would probably benefit from a BDD-capable framework like Jasmine, as opposed to just pure TDD (ala the results you found of a visual diff being a mess to do), as you are testing behavior and comparisons and prior/post states of functionality/behavior, not just if a is true and still true after being parsed.
设置这些单元测试可能要花一些时间，但是它是使用大量代码库的迭代方法...快速，早地测试您的初始关键阻塞点或易碎点，然后将测试扩展到所有内容(我的方式是一直以来，我的团队都建立了这样的观点:从现在开始，任何东西都不会被认为是完整的，除非有单元测试，否则RC ...任何没有单元测试并且必须更新/修改/维护的旧东西都必须在编写时编写单元测试被触动，因此您将以一种更易于管理和更合理的方式不断改进和缩小未经测试的代码量，同时增加代码覆盖率.
Setting up these Unit Tests could take a while, but its an iterative approach with that large of a codebase...test your initial critical choke points or fragile points fast and early, then extend tests to everything (the way I've always set my teams up is that anything from this point on is not considered complete and RC unless it has Unit Tests...anything old that has no Unit Tests and has to be updated/touched/maintained must have Unit Tests written when they are touched, so that you are constantly improving and shrinking the amount of untested code in a more manageable and logic way, while increasing your code coverage).
一旦在CI中启动并运行了单元测试，就可以将其绑定到构建过程中:没有单元测试的构建失败，或者当单元测试失败时发出警报，对每个签入进行主动监视等等.使用JSDoc3等自动生成文档等.
Once you have Unit Tests up and running in a CI, you can then tie them into your build process: fail builds that have no unit tests, or when the unit tests fail send out alerts, proactively monitor on each checkin, etc. etc. Auto-generate documentation with JSDoc3, etc. etc.
您要描述的问题是构建CI和单元测试的目的，更具体地说，在您的情况下，这种方法可以最大程度地减少代码库大小的影响...大小不会使代码库变得更复杂，只会使全面进行测试的持续时间.
The issue you are describing is what CI and Unit Tests were built for, and more specifically in your case that approach minimizes the impact of the size of the codebase...the size doesn't make it more complex, just makes the duration to get testing working across the board longer.
然后，将其与JSDoc3结合使用，您的样式就会比大多数前端商店的90％好.在那时，它的功能极其强大且对工程师有用，并且可以自我延续.
Then, combine that with JSDoc3 and you are styling better than 90% of most front end shops. Its incredibly robust and useful to engineers at that point, and it becomes self-perpetuating.
我真的可以继续讨论这个话题，您如何处理这个问题并让团队团结起来使其自我形成和永存，这方面有很多细微差别，最重要的是写作可测试的代码...但是从概念上来说... 编写单元测试并使其自动化.总是.
I really could go on and on about this topic, there's a lot of nuance to how you approach it and get a team to rally behind it and make it self-forming and self-perpetuating, and the most important one being writing testable code...but from a concept level...write unit tests and automate them. Always.
长期以来，前端开发人员一直在半途而废地进行开发，没有采用实际的工程严格性和纪律性.随着前端变得越来越强大和炙手可热，这必须改变并且正在改变.前端/RIA应用程序经过良好测试，覆盖范围广，自动化测试和持续集成的概念是这一变更的巨大需求之一.
For too long frontend devs have been half-assing development, not applying actual engineering rigor and discipline. As frontend has grown more and more powerful and hot, that has to change, and is changing. The concept of well tested, well covered, automated testing and continuous integration for frontend/RIA applications is one of the huge needs of that change.
这篇关于如何测试JavaScript缩小输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
