如何确定哪个nodeunit导致异步错误更快?

时间:2019-06-22 19:44:20

标签: javascript node.js asynchronous node-modules async.js

在测试相当大的重构时遇到了一个问题(在这种情况下,将旧服务从node.js 0.12迁移到10.x)。我们使用grunt,所以我从grunt nodeunit:all中得到了以下结果:

...
verify-api.routes.test.js
test setValues (pass)
Fatal error: Cannot read property 'setUp' of undefined

一些谷歌搜索会导致多个线程-this one是一个很好的提要-正确显示此错误是多次调用test.done时。

太好了!没问题。有了这些,您现在就可以进入verify-api.routes.test.js,在其中您可以看到/假定问题基于输出而定位。唯一-您错了。事实证明,在整个测试套件中,错误(就我而言)位于两个测试套件之前 verify-api.routes.test.js。公平地说,这部分是部分咕output的过错,因为输出会误导我们识别verify-api.routes.test.js ...但是如底部所示,其他方式只是更清楚地表明nodeunit不知道问题出在哪里-只会稍微好一点。

我发现我偶尔可能会遇到这样的问题-但是当它发生时会很痛苦...这种情况尤其令人痛苦,因为它们通常仅偶尔出现-例如在发布时或看似良性的合并之后。

人们是否正在使用一种快速的技巧来发现这些问题或使他们的代码对这些类型的问题更具弹性?


如上所述,某些节点单元运行程序提供了不同的结果……更多/更少的误导取决于上下文:

直接使用nodeunit tests/**/*.test.js

运行nodeunit时,得到以下输出
OK: 162 assertions (2720ms)

FAILURES: Undone tests (or their setups/teardowns): 
- test setValues

这是通过Intellij的IDEA进行的,它很好地为我们提供了更多信息:

./node_modules/nodeunit/lib/core.js:285
    if (group.setUp) {
              ^
TypeError: Cannot read property 'setUp' of undefined
    at wrapGroup (./node_modules/nodeunit/lib/core.js:285:15)
    at Object.exports.runSuite (./node_modules/nodeunit/lib/core.js:93:13)

1 个答案:

答案 0 :(得分:0)

所以-我正在寻找对此类问题有帮助的最佳实践。出于防卫目的,我接下来会提到一些我认为很重要的事情,然后花一些时间在今天对我有帮助的策略上……

1。持续集成

尽可能频繁地运行测试,可以更准确地向您显示导致问题的更改。当您有很多测试或长时间运行的测试时,您可能会发现无法全部运行它们(如上所述),而是重构重要的测试以使其更快。同样按区域运行测试也可以提供帮助。

2。同行评审/配对编码

通常可以很好地捕获问题的发生或之后不久的时间,从而节省调试和维护方面的调试时间,以换取更多的前期时间。

3。使用async

如果您是异步编程,那么您确实应该研究此库,以使您的代码更简洁。异步还具有几乎不可思议的组件,可以处理异步依赖关系管理,过滤等。如果您正在开发节点代码,请立即获取(异步)[https://github.com/caolan/async]


最后但并非最不重要的...今天对我最大的帮助是使用find独立运行测试:

4。使用find

独立运行测试

今天对我最大的帮助是使用“查找”隔离运行测试。在此之前,我们可能将测试分成几组,以尝试缩小搜索空间(即二进制搜索样式),直到获得有用的结果为止。

我在程序包脚本中创建了一个规则来为我执行此操作-进行一些回显,以便更清楚地了解哪些输出属于哪些测试:

"find-run-all-tests": "time find . -not -path \"./node_modules/*\" -type f -name \"*.test.js\" -exec echo \\n----------- Testing : {} --------------- \\; -exec node_modules/nodeunit/bin/nodeunit {} \\; -exec echo ----------- Finished : {} --------------- \\; ",

这当然使我们可以从项目中npm run find-run-all-tests。这样做的好处是:a)运行项目指定的nodeunit版本,b)向我们显示整个套件花费了多少时间,c)创建的输出明确表明问题出在哪个套件上,并且d)运行了每个测试每次完全隔离时重新启动节点(此处会降低性能):

tokenoftrust-routes.test.js

✔ test login with basic privileges works.
✔ non-privileged access of privileged page. - when user is not logged in they should be directed to log-in
✖ non-privileged access of privileged page. - when user is logged in they should get an error page

FAILURES: Undone tests (or their setups/teardowns): 
- non-privileged access of privileged page. - when a non-test user is logged in they should STILL be able to see Developer Home

To fix this, make sure all tests call test.done()

----------- Testing : ./website/tests/apiKeysInvite-routes.test.js ---------------
----------- Testing : ./tests/services/requestService.test.js ---------------

requestService.test.js
✔ request service - expire request works.
✔ request service basic CRUD operations on objects work.
✔ request service basic CRUD operations on simple types.

OK: 15 assertions (834ms)
----------- Finished : ./tests/services/requestService.test.js ---------------

再次-我看不到我们一直在性能成本方面一直这样做。在我们的案例中,测试花费了5倍的时间才能运行BUT,而花费的额外时间却只有4分钟,这帮助我隔离了我们在大量测试套件中隔离出一系列问题,从而使我们跳过了一些我们发现自己适得其反的侦查工作在做。


这是一个奇怪的情况,在进行了非常广泛的更改后,我们被迫走这条路,但我想知道其他人是否/确实经历过这种痛苦,如果是,那么您正在采取什么措施来缓解这种痛苦/问题。如果我缺少明显的东西或者您正在使用的骇客程序可以节省您的时间,请分享。

随着我们进行更多的测试,我发现这种情况变得越来越频繁和昂贵,因此我们需要变得更好和更快。