Мощная правда.

Посмотрите на следующий простой и понятный код:

function sum(a, b) {
  return a   b;
}

Теперь давайте напишем для него несколько тестов:

test('sum', () => {
  expect(sum(1, 2)).toBe(3);
  expect(sum(2, 3)).toBe(5);
  expect(sum(3, 4)).toBe(7);
  expect(sum(4, 5)).toBe(9);
});

У нас 100% охват, верно? Ну да, есть, на самом деле мы могли бы сказать, что получили 400%-ное покрытие, поскольку весь код полностью протестирован 4 раза, но так ли?

Правда в том, что мы этого не делаем. Мы тестируем функцию с ограниченным набором входных данных и не рассматриваем крайние случаи, а также не тестируем функцию с недопустимыми входными данными.

Учитывайте следующее:

sum(1, '2');
sum(1, null);
sum(1, undefined);

Что произойдет в таком случае? Будет ли функция выдавать ошибку? Будет ли он возвращать значение? Не сломает ли это наше приложение?

Помните о ловушке тестового покрытия.

Тестовое покрытие — мощный инструмент, но не окончательное решение. Это показатель, который может помочь вам понять, какая часть вашего кода тестируется, но не говорит о том, насколько хорошо он тестируется.

Тестовое покрытие может помочь вам с количеством, но мало что может сделать с качеством. Вам предстоит писать хорошие тесты, учитывать крайние случаи, тестировать свой код с недопустимыми входными данными и следить за тем, чтобы ваши тесты были значимыми и ценными.

Заключение

Признаюсь, это была довольно короткая статья, но все же надеюсь, что она была вам полезна как напоминание о важности написания хороших тестов. Помните, что тестовое покрытие — это инструмент, а не цель. Вам решать, как извлечь из этого максимум пользы.

Чао,

Майкл.