Напишите отличные модульные тесты, написав неудачные модульные тесты
web-monetization software-development software-testing software-qa unit-testing javascript software-engineering software-design unit-test

Напишите отличные модульные тесты, написав неудачные модульные тесты

6 июня 2022 г.

Да, серьезно…

Около года назад я наткнулся на эту публикацию на LinkedIn, написанную Крейгом Ливингсом. заявление:

<цитата>

Любой тест, который никогда не давал сбоев, не добавляет ценности #tdd #agile

Mind blown 🤯

Это означает, что любой тест, который никогда не давал сбоев, не имеет ценности и, следовательно, может быть удален. Чтобы какой-либо тест принес пользу, он должен хотя бы раз не пройти проверку.

Давайте посмотрим, почему способность проваливать тесты является таким важным навыком…

Почему наши тесты должны провалиться?

Допустим, мы написали некоторый код и несколько вспомогательных модульных тестов. Мы хорошо потрудились? Тесты никогда не подводили, но теперь у нас есть модульные тесты, поддерживающие наш код! Или, по крайней мере, мы думаем, что у нас есть…

Давайте посмотрим на некоторые примеры. Один из тестов, который не провалился, и тот, который провалился.

Тест, который никогда не подводил

Этот пример является распространенным сценарием, когда мы просто сосредоточены на написании теста, который проходит. У нас нет намерения сделать это неудачным.

Мы будем использовать следующую функцию JavaScript:

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

module.exports = sum;

Мы написали следующий тест Jest, чтобы проверить, что наша функция sum складывает два числа вместе:

const sum = require('./sum');

test('two plus two is four', () => {
  expect(2 + 2).toBe(4);
});

Запускаем тест и он проходит ✅

Вот и все. Мы рады, что тест пройден, поэтому идем дальше.

Проверка не удалась

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

Используя ту же функцию:

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

module.exports = sum;

И используя тот же тест:

const sum = require('./sum');

test('two plus two is four', () => {
  expect(2 + 2).toBe(4);
});

Запускаем тест и он проходит ✅

Но на этот раз мы хотим, чтобы тест провалился. Поэтому мы решили изменить код:

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

module.exports = sum;

Повторно запускаем тест и получаем еще один проход ✅

Но подождите... это должно было потерпеть неудачу. Мы удалили код, который складывает числа вместе.

Мы видим, что причина, по которой тест все еще пройден, заключается в том, что сам тест неверен. Тест не вызывал sum.

Итак, мы обновляем тест:

const sum = require('./sum');

test('two plus two is four', () => {
  expect(sum(2, 2)).toBe(4);
});

Мы повторно запускаем тест, и он терпит неудачу ❌

Ок, отлично! Теперь давайте вернем наш код:

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

module.exports = sum;

И мы повторно запускаем тест, и он проходит ✅

Отлично, теперь наш тест имеет ценность, потому что мы убедились, что тест проверяет правильность.

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

Вывод

При написании тестов мы должны знать, что они не пройдены, поэтому мы знаем, что они приносят пользу.

Вы согласны?

Первая публикация здесь

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE