Неприятные ошибки при написании юнит тестов05.12.2018 08:49

На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.

Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными —, но даже опытные разработчики могут случайно написать такой код.

Итак, поехали.

0. Отсутствие тестов

Как ни странно, до сих пор многие считают, что написание тестов замедляет скорость разработки. Конечно, это очевидно, что больше времени приходится тратить на то, чтобы писать тесты, и чтобы писать код, который можно тестировать. Но на отладку и регрессы после этого придётся тратить в разы больше времени…

1. Отсутствие запуска тестов

Если у вас есть тесты, которые вы не запускаете, или запускаете от раза к разу — то это всё равно что отсутствие тестов. И это даже хуже — у вас есть устаревающий код тестов и ложное чувство безопасности. Тесты как минимум должны запускаться в CI процессах при пуше кода в ветку. А лучше — локально перед пушем. Тогда разработчику не придётся через несколько дней возвращаться к билду, который, как оказалось, не прошёл.

2. Отсутствие покрытия

Если вы ещё не знаете, что такое покрытие в тестах, то самое время во прямо сейчас пойти и прочитать. Хотя бы википедию. Иначе велики шансы того, что ваш тест будет проверять от силы 10% от того кода, который, как вы думаете, он проверяет. Рано или поздно вы на это обязательно наступите. Конечно, даже 100% покрытие кода никак не гарантирует его полную корректность —, но это гораздо лучше, чем отсутствие покрытия так как покажет вам гораздо больше потенциальных ошибок. Недаром в последних версиях Node.JS даже появились встроенные инструменты для того, чтобы его считать. Вообще, тема покрытия глубокая и крайне холиварная, но не буду в неё слишком углубляться — хочется сказать по понемножку о многом.

3.

const {assert} = require('chai');
const Promise = require('bluebird');

function someLongFunction()
{
  return Promise.delay(10000);
}

describe('using Timeout', ()=>{
  it('should cancel after 1 second', async ()=>{
    let timedOut = false;
    try {
      await someLongFunction().timeout(1000);
    }
    catch (err)
    {
      if (err instanceof Promise.TimeoutError)
      {
        timedOut = true;
      }
      else
      {
        throw err;
      }
    }
    assert.equal(timedOut, true);
  });
});

4.

const testData = require('./testData.json');
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);
  });
});

  afterEach(() => {
    sinon.sandbox.restore();
  });

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. Отсутствие моков

Гораздо проще запускать тесты с живой базой и сотальными сервисами, и гонять тесты на них.
Но рано или поздно это аукнется — тесты по удалению данных выполнятся на продуктовой базе, начнут падать из-за неработающего партнёрского сервиса, или в вашем 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);
  });
});

1) badCompare
       should throw only my custom errors:

      AssertionError: expected false to be true
      + expected - actual

      -false
      +true

      at Context.it (test/011_badCompare/test.js:23:14)

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();
  });
});

Вот такая вот подборка вышла. Все эти тесты отлично проходят проверки, но они broken by design. Добавляйте свои варианты в комментарии, или в репозиторий, который я сделал для собирания таких ошибок.

© Habrahabr.ru