День 1847. #Testing
Компромиссы при Написании Тестов
Многие компании стремятся иметь 100% покрытия кода. Даже делают частью процесса CI/CD проверки, чтобы гарантировать, что покрытие тестами всегда увеличивается. Это имеет несколько последствий.

Запланированный эффект - разработчики пишут больше тестов. Незапланированный - иногда они пишут плохие тесты, либо просто костыли, чтобы «обмануть» проверку. Например, если вы провели рефакторинг хорошо протестированного кода, уменьшив его объём, покрытие кода уменьшится, но кодовая база улучшится.

Стремиться к 100% покрытию кода — плохая идея, но где провести черту?

Зачем мы пишем тесты?
В конечном счёте тесты обслуживают код, который мы пишем, и предназначены для решения проблемы. Если добавление теста не помогло решить проблему, это лишь трата времени и денег. Тесты снижают риск, позволяют проверить вашу работу и убедиться, что она скорее всего верна. Каждый тест даёт вам немного больше уверенности в тестируемом коде. Ценность тестового кода не прямая. Она в предотвращении потерь, как с точки зрения реального ущерба от ошибок (потеря дохода, нарушение конфиденциальности, неверные результаты), так и с точки зрения времени на обнаружение и исправление этих ошибок. Нам не нравится платить эту цену, поэтому вместо этого мы платим за тесты. Это страховка.

Какие риски вы хотите покрыть?
Как страховые полисы имеют разное покрытие, лимиты и доп. услуги за дополнительную цену, так с количеством тестов. Мы не можем позволить себе покрыть все риски. Нужно выбрать, сколько платить в виде «страховой премии» и сколько - в случае аварии. При 100% покрытии кода вы хотите избежать риска любой ошибки. А если тестов нет, значит даже серьёзные ошибки с максимальной стоимостью вас не беспокоят.

Как выбрать, какой риск мы хотим покрыть при тестировании? Часто это неявное решение: кто-то считает, что «больше покрытия кода, это хорошо», а затем люди начинают писать больше тестов, потому что «это наша культура, чувак»! Лучший способ – обдумать решение.

Есть тесты, которые мы обязаны написать. Если вы работаете над кардиостимулятором, планка минимального тестирования (и других форм гарантии) высокая, т.к. от этого зависит жизнь человека. Далее допустим, что минимальный набор тестов у нас есть, и мы решаем, писать ли другие тесты. Проблема, что компромисс между риском и стоимостью трудно оценить количественно.

Нужно сравнить два числа:
1. Стоимость написания тестов
Сколько времени (в % от задачи) тратится на тестирование всеми членами команды. Не нужно измерять это для каждой задачи, сделайте выборку, чтобы получить примерное значение.
2. Стоимость ошибок
Это сложнее. Некоторые ошибки имеют явную цену, например отток клиентов. Но цена многих скрыта, например, подрыв доверия или иной вред. Измерьте время, которое команда тратит на выявление и исправление ошибок - это одна из основных трат. Бизнес затраты придётся оценить вместе с руководством. Идея в том, чтобы оценить общие затраты как можно более точно.

Получив эти числа, можно искать компромисс. Очевидно, что стоимость написания тестов должна быть ниже стоимости ошибок. Но не забудьте, что написание тестов вместо кода связано с альтернативными издержками. Если срок выхода продукта критичен для существования компании, лучше приложить все усилия к созданию функций и свести к минимуму тестирование. Это не бесплатный компромисс, потому что вы заплатите за эти ошибки позже.

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

Как вы решаете это в своей команде? У вас есть цель обеспечить покрытие кода?

Источник: https://ntietz.com/blog/too-much-of-a-good-thing-the-cost-of-excess-testing/