您的位置: 首页  >  技术问答  >  单元测试karma-runner / jasmine profiling

单元测试karma-runner / jasmine profiling

分类: 技术问答 • 2022-02-24 17:57:14

单元测试karma-runner / jasmine profiling

问题描述：

对于单元测试，我们使用grunt / karma-runner / jasmine / phantom.js。因为我们试图涵盖任何新功能，所以许多单元测试会迅速增长。不幸的是，测试时间也在增加。
现在它并不重要，1000次测试需要10秒，但情况越来越糟。

For unit-tests we use grunt/karma-runner/jasmine/phantom.js. Because we try to cover any new functionality, a number of unit-tests grows up rapidly. And, unfortunately, time for tests also increasing. Now it is not critical and takes 10 seconds for 1000 tests, but it goes worse and worse.

问题：


  1. 我知道，有些测试写得不好（耗费大量时间），但我应该优化哪一项？是否存在某些业力/茉莉花探查器来衡量每次测试的时间执行情况？

  1. I know, some of the tests are bad-written (a lot of time consuming), but which one I should optimize? Is it exist some karma/jasmine profiler which measure time execution for each test?

我可以开始更多业力 - 跑者线程/进程，因为CPU仅用于5％-10％？单元测试真的是独立的。

Can I start more karma-runner threads/processes, because CPU used only for 5%-10%? Unit-tests really independent.

每当我保存文件时，karma：watch开始所有测试，可能存在 karma-runner的一些选项，它只重新启动当前文件夹的测试（我们使用规则：单元测试file.spec.js存储在与源文件.js相同的文件夹中）？

Each time when I save file, karma:watch starts all tests, may be exist some option for karma-runner, which re-starts only tests for current folder (we use rule: unit tests file.spec.js stored in the same folder as source file.js)?

谢谢，

update1：​​有人建议我使用 iit / ddescribe for jasmine （与mocha的.only相同），它是开发/调试的绝佳选择，但可能存在其他方式吗？

update1: Someone suggest me use iit/ddescribe for jasmine (the same as .only for mocha) and it is great option for develop/debugging, but may be exist some other way ?

我将问题发布到karma-user论坛此处。

I post the question to karma-user forum here.

答

查找慢速测试


  • reportSlowerThan （点或进度报告器将报告所有比ms中给定数字慢的测试），

  • reportSlowerThan (dots or progress reporter will report all the tests that are slower than given number in ms),

你ca n跳转到浏览器并以与使用应用程序相同的方式配置测试（例如， Chrome中的火焰图非常棒。

you can jump to the browser and profile your tests in the same way you would do it with an app (eg. flamecharts in Chrome are awesome).

让测试更快


  • 并行化：

我们正在研究这个问题。您将能够跨多个浏览器并行化测试。当然，这些浏览器不必在同一台机器上运行，因此您也可以使用多台机器。

We are working on this. You will be able to parallelize the tests across multiple browsers. Of course, these browsers don't have to run on the same machine so you will be able to use multiple machines too.

我不认为运行多个实例Karma本身会有很大的帮助，因为它是以一种非非阻塞的方式编写的，我并没有把它看成是瓶颈。但是我们应该优化CPU /内存使用量。这方面的许多改进都将在v0.12中进行。

I don't think running multiple instances of Karma itself would help that much, as it is written in a very "non-blocking" way and I haven't seen it to be the bottleneck. We should however optimize the CPU/memory usage. A lot of improvements in this area is coming in v0.12.

只运行一部分测试：

你应该完全使用 iit / ddescribe （Jasmine）。这不适合你的任何理由？顺便说一句。 Mocha的 it.only（）和 describe.only（）的实现有问题，所以我推荐Jasmine（或修复） Mocha）。

You should totally use iit/ddescribe (Jasmine). Any reason why this does not work for you? Btw. Mocha's implementation of it.only() and describe.only() has issues, so I recommend Jasmine (or fixing Mocha).

还有一个Google Closure的原型插件只加载你真正需要的文件（比如你 iit 一个测试，它只会加载/解析/评估你真正需要的文件 iit ）。这大大改善了大型项目的开始时间 - 我们应该为其他模块加载器（RequireJS，CommonJS）做类似的技巧。

There is also a prototype of Google Closure plugin which only loads the files you really need (say you iit one test, it will only load/parse/evaluate the files you really need for that iit). This improves start time on huge projects significantly - we should do similar tricks for other module loaders (RequireJS, CommonJS).

编写更快的代码：

你可能已经知道了......; - ）

You probably know this already... ;-)

DOM很慢。逻辑/ DOM的良好分离将允许您在不实际触摸DOM的情况下测试更多内容。如果您使用Angular，您可以查看测试指令示例。

DOM is slow. A good separation of logic/DOM will allow you to test more stuff without actually touching DOM. If you use Angular, you might check out the testing directives example.

使用依赖注入模式有很大帮助，因为您基本上可以最大限度地减少每个测试准备（以及拆除）所需的环境。这是一个例子。

Using Dependency Injection pattern helps a lot as you basically minimize the environment you need to prepare (and also tear down) for each test. Here's an example.

一般来说，较低的较低测试更快。我认为用尽可能低的测试来覆盖每个功能/问题是好的。

In general, lower lower tests are faster. I think it's good to cover each functionality/issue with lowest possible test.

消除内存泄漏：

如果您的测试泄漏内存，浏览器将变得越来越慢，因此即使编写得很好，测试编号1000也会非常慢。确保每个测试释放所有引用。您可以使用 http：// localhost：9876 / debug.html 并分析内存。执行前检查内存（在Jasmine执行所有 describe（）块并收集测试后），然后在执行测试后 - 它应该是相同的。

If your tests leak memory, the browser will get slower and slower and so the test number 1000 will be pretty slow even though it's well written. Make sure each test frees up all the references. You can use http://localhost:9876/debug.html and profile the memory. Check the memory before executing (after Jasmine executed all the describe() blocks and collected the tests) and then after executing the tests - it should be the same.

发现一些内存泄漏比其他内存更难，但它可以显着提高速度 - 我已经看到了从大约5分钟到不到一分钟的东西只是通过消除内存泄漏。

Finding some memory leaks is harder than others, but it can significantly improve the speed - I've seen stuff like from ~5mins to under a minute just by eliminating memory leaks.

相关推荐