Юнит-тестирование — неправильно понятая концепция

То тут, то там я встречаю жалобы на «модульные тесты». Вот несколько примеров:

❌»Юнит-тесты трудно писать».
✅(Да, если кодовая база находится в плохой форме и/или не была разработана с учетом тестируемости)

❌»Юнит-тесты хрупкие»
✅(Да, обычно когда вы пишете тесты ради достижения каких-то целей по покрытию)

❌»Юнит-тесты проверяют только техническую реализацию, а не ценность для бизнеса».
✅(Да, если это способ написания тестируемого кода)

У меня такое чувство, что некоторые люди слишком озабочены «что» и «как», забывая при этом о «почему».

❓ Зачем мы пишем тесты?
👉 Чтобы подтвердить, что код, который мы собираемся отправить на следующий этап, не является очевидно и/или ужасно сломанным

❓Почему мы можем предпочесть более мелкие («юнит») тесты?
👉 Они быстрее (иногда в 600 раз быстрее!)
👉 Они более сфокусированы. Они тестируют небольшие фрагменты бизнес-логики, поэтому в случае неудачи теста обычно есть представление о том, что может быть не так
👉При проведении TDD нам может быть неудобно сосредоточиться на сложном поведении, не проверив сначала более мелкие модели поведения
👉 Они работают как принудительная функция. По моему опыту, существует сильная положительная корреляция между тем, насколько легко писать небольшие тесты (т.е. тестируемость кода), с читаемостью и сопровождаемостью кода.

Теперь это имеет больше смысла?

Оцените статью
devanswers.ru
Добавить комментарий