编写单元测试时出现令人不快的错误

前几天，我将做一个内部报告，在其中我将告诉我们的开发人员有关编写单元测试时可能发生的令人不愉快的错误。 从我的角度来看，最不愉快的错误是测试通过时，但同时它们做得如此错误，以至于最好不通过。 我决定与所有人分享此类错误的示例。 当然，这方面还有其他要说的。 示例是针对Node.JS和Mocha编写的，但是通常这些错误对于其他任何生态系统都是正确的。

为了使问题更有趣，其中一些以问题代码和扰流器的形式被框起来，将其打开，您将看到问题出在哪里。 因此，我建议您首先查看代码，在其中找到错误，然后打开扰流板。 没有指出解决问题的方法-我建议自己考虑一下。 只是因为我很懒。 列表的顺序没有什么深远的意义，它只是一个顺序，在此顺序中，我回顾了使我们流泪的各种实际问题。 当然，许多事情对您来说似乎显而易见-但即使是经验丰富的开发人员也可能会意外地编写此类代码。


所以走吧

0.缺乏测试

奇怪的是，许多人仍然认为编写测试会降低开发速度。 当然，很明显，必须花费更多的时间编写测试和编写可以测试的代码。 但是经过调试和回归之后，您必须花费更多的时间...

1.缺乏运行测试

如果您有不运行的测试，或者不时运行，则就像没有测试一样。 更糟糕的是-您的测试代码已经过时，并且对安全性有错误的认识。 将代码推送到分支时，测试至少应在CI进程中运行。 更好-在推动之前就在本地。 然后，开发人员将不必在几天之内返回构建，事实证明，构建并没有通过。

2.缺乏覆盖

如果您仍然不知道测试的覆盖范围，那么该是现在就开始阅读。 至少维基百科 。 否则，您的测试很有可能会检查您认为检查的代码强度的10％。 迟早您肯定会踩到它。 当然，即使代码的100％覆盖率也不能以任何方式保证其完全正确性-但这比缺少覆盖率要好得多，因为它将向您显示更多潜在的错误。 难怪最新版本的Node.JS甚至具有内置的读取工具。 总的来说，报道的主题是非常深入和全面的，但是我不会太深入-我想说很多。

3。

const {assert} = require('chai'); const Promise = require('bluebird'); const sinon = require('sinon'); class MightyLibrary { static someLongFunction() { return Promise.resolve(1); // just imagine a really complex and long function here } } async function doItQuickOrFail() { let res; try { res = await MightyLibrary.someLongFunction().timeout(1000); } catch (err) { if (err instanceof Promise.TimeoutError) { return false; } throw err; } return res; } describe('using Timeouts', ()=>{ it('should return false if waited too much', async ()=>{ // stub function to emulate looong work sinon.stub(MightyLibrary, 'someLongFunction').callsFake(()=>Promise.delay(10000).then(()=>true)); const res = await doItQuickOrFail(); assert.equal(res, false); }); }); 

4。

 const fs = require('fs'); const testData = JSON.parse(fs.readFileSync('./testData.json', 'utf8')); describe('some block', ()=>{ it('should do something', ()=>{ someTest(testData); }) }) 

5，

 const {assert} = require('chai'); const sinon = require('sinon'); class Dog { // eslint-disable-next-line class-methods-use-this say() { return 'Wow'; } } describe('stubsEverywhere', ()=>{ before(()=>{ sinon.stub(Dog.prototype, 'say').callsFake(()=>{ return 'meow'; }); }); it('should say meow', ()=>{ const dog = new Dog(); assert.equal(dog.say(), 'meow', 'dog should say "meow!"'); }); }); 

6。

 const sinon = require('sinon'); const {assert} = require('chai'); class Widget { fetch() {} loadData() { this.fetch(); } } if (!sinon.sandbox || !sinon.sandbox.stub) { sinon.sandbox = sinon.createSandbox(); } describe('My widget', () => { it('is awesome', () => { const widget = new Widget(); widget.fetch = sinon.sandbox.stub().returns({ one: 1, two: 2 }); widget.loadData(); assert.isTrue(widget.fetch.called); }); }); 

7.测试文件中的大量测试数据

我经常看到直接在测试中放置着巨大的JSON文件，甚至XML。 我认为很明显为什么这样做不值得-观看，编辑变得很痛苦，任何IDE都不会为此感到感谢。 如果测试数据较大，请将其从测试文件中删除。

8。

 const {assert} = require('chai'); const crypto = require('crypto'); describe('extraTests', ()=>{ it('should generate unique bytes', ()=>{ const arr = []; for (let i = 0; i < 1000; i++) { const value = crypto.randomBytes(256); arr.push(value); } const unique = arr.filter((el, index)=>arr.indexOf(el) === index); assert.equal(arr.length, unique.length, 'Data is not random enough!'); }); }); 

9.缺乏魔力

使用实时数据库和100％服务运行测试，并在它们上运行测试要容易得多。
但是迟早会恢复成功-数据删除测试将在产品基础上执行，由于合作伙伴服务中断而开始下降，或者您的CI根本没有运行它们的基础。 通常，该项目非常全面，但通常来说-如果您可以模拟外部服务，则最好这样做。

11。

 const {assert} = require('chai'); class CustomError extends Error { } function mytestFunction() { throw new CustomError('important message'); } describe('badCompare', ()=>{ it('should throw only my custom errors', ()=>{ let errorHappened = false; try { mytestFunction(); } catch (err) { errorHappened = true; assert.isTrue(err instanceof CustomError); } assert.isTrue(errorHappened); }); }); 

12

 const {assert} = require('chai'); function someVeryBigFunc1() { return 1; // imagine a tonn of code here } function someVeryBigFunc2() { return 2; // imagine a tonn of code here } describe('all Before Tests', ()=>{ let res1; let res2; before(async ()=>{ res1 = await someVeryBigFunc1(); res2 = await someVeryBigFunc2(); }); it('should return 1', ()=>{ assert.equal(res1, 1); }); it('should return 2', ()=>{ assert.equal(res2, 2); }); }); 

13

 const {assert} = require('chai'); const moment = require('moment'); function someDateBasedFunction(date) { if (moment().isAfter(date)) { return 0; } return 1; } describe('useFutureDate', ()=>{ it('should return 0 for passed date', ()=>{ const pastDate = moment('2010-01-01'); assert.equal(someDateBasedFunction(pastDate), 0); }); it('should return 1 for future date', ()=>{ const itWillAlwaysBeInFuture = moment('2030-01-01'); assert.equal(someDateBasedFunction(itWillAlwaysBeInFuture), 1); }); }); 

14。

 describe('dynamicRequires', ()=>{ it('should return english locale', ()=>{ // HACK : // Some people mutate locale in tests to chinese so I will require moment here // eslint-disable-next-line global-require const moment = require('moment'); const someDate = moment('2010-01-01').format('MMMM'); assert.equal(someDate, 'January'); }); }); 

15

 function someComplexFunc() { // Imagine a piece of really strange code here return 1; } describe('cryptic', ()=>{ it('success', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('should not fail', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('is right', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('makes no difference for solar system', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); }); 

16。

 const {assert} = require('chai'); const Promise = require('bluebird'); function someTomeoutingFunction() { throw new Promise.TimeoutError(); } describe('no Error check', ()=>{ it('should throw error', async ()=>{ let timedOut = false; try { await someTomeoutingFunction(); } catch (err) { timedOut = true; } assert.equal(timedOut, true); }); }); 

17。

 function someBadFunc() { throw new Error('I am just wrong!'); } describe.skip('skipped test', ()=>{ it('should be fine', ()=>{ someBadFunc(); }); }); 

这样的选择出来了。 所有这些测试都很好地通过了测试，但是它们被设计破坏了。 将您的选项添加到注释或我为收集此类错误而创建的存储库中 。