Качество намного лучше, чем количество. Один хоумран намного лучше, чем два дубля.
- Стив Джобс
В идеалистическом мире покрытие кода является обязательным, когда субъект измеряет качество кода, чем выше, тем лучше — это естественно. Но в последнее время у меня другие мысли.
Я видел много случаев, когда покрытие юнит-тестами в проекте было довольно высоким, и оно не улавливало многих проблем, представленных в открытых ошибках, вызванных изменениями кода — когда следовало бы. На самом деле эти тесты в основном только препятствовали сборке набора тестов с некоторыми раздражающими ошибками компиляции при рефакторинге чего-либо. Но почему это происходило? Возможно, целевой показатель покрытия кода. Почему? Я попытаюсь ответить на этот вопрос с помощью вымышленного учебного случая.
Вымышленный учебный случай
Допустим, есть проект, в котором разработчики должны создать модульные тесты, чтобы обеспечить целевое покрытие тестами в 70%. Разработчик закончил разработку своей истории и теперь он проведет модульное тестирование, примет во внимание эти факты для этого проекта и истории:
- В этом проекте у разработчиков в среднем есть 1 час на создание модульных тестов для каждой истории;
- Для завершения этой истории потребовалось создать 15 методов;
- Из этих 15 методов только 3 из них на самом деле имели соответствующую логику, которую нужно было регрессировать, но для их тестирования требовалось больше работы;
Возможные результаты
Результат 1
- Разработчик будет искать более крупные и простые методы, позволяющие выполнять меньше тестов и соответствовать целевому охвату тестами;
- Эти 3 соответствующих метода не будут тестироваться;
Результат 2
- Разработчик протестирует все методы, включая те 3 релевантных, чтобы обеспечить целевое тестовое покрытие;
- К сожалению, ветки будут пропущены, и эти ветки будут иметь значение для этих трех соответствующих методов;
Значение тестовой ветки: один из возможных результатов при выполнении метода.
Результат 3
- Разработчик попросит больше времени и будет стремиться к 100% охвату;
- Ему будет отказано более чем на 2 часа, так как график плотный;
- Есть шанс, что времени все равно не хватит, чтобы охватить ветки этих 3-х методов;
И, в конце концов, к сожалению, несмотря на то, что разработчику удалось достичь цели по охвату кода, ошибки все же возникали, когда другие разработчики изменяли этот код в будущем.
Заключение истории
Иногда на внедрение модульных тестов для достижения целевого покрытия тратится много драгоценного времени, но есть вероятность, что этого будет недостаточно для предотвращения ошибок в будущем, поскольку они не охватывают все ветки в этих 3 чертовски важных методы.
Что можно сделать, чтобы спасти положение
Для этой выдуманной истории — и суть этой статьи — в том, что если бы у разработчика был этот 1 час, чтобы создать модульные тесты только для тех 3 чертовски релевантных методов, которые он знал были важны, возможно, багов можно было бы избежать, поскольку на них был возможен 100% охват ветки, и потенциально у него все еще оставалось время, чтобы увидеть милые фотографии собак в Интернете.
Кроме того
Иногда целые слои игнорируются, потому что их сложнее проводить модульное тестирование, как это обычно бывает со слоем пользовательского интерфейса в мобильных приложениях. Хотя в некоторых проектах этот уровень покрывается тестами пользовательского интерфейса, поскольку они более затратны, они вряд ли охватывают все ветки тестирования, где это важно.
Дело здесь
Покрытие кода не является источником истины для качества, было бы намного продуктивнее создавать модульные тесты только для методов/фрагментов кода, которые разработчики считают необходимыми. Таким образом, не будет теряться время на бессмысленные тесты, а места, где это действительно важно, будут позаботиться обо всем — в конечном счете, уменьшится количество ошибок в долгосрочной перспективе.
Заключение
Тестовое покрытие важно — это факт. Но это не всегда единственное, что нужно учитывать, когда речь идет об уменьшении количества ошибок за счет модульного тестирования.
Выполнение действий, указанных в этой статье, может улучшить качество, но также создает некоторые новые проблемы:
- Как измерить качество? Отслеживание количества ошибок может быть хорошим началом;
- Как узнать, куда добавлять тесты? Это будет зависеть исключительно от суждения разработчиков о том, что следует тестировать, и при поддержке других разработчиков во время проверки кода;
Это мое размышление об этом. Если бы у меня была возможность принять это решение, я бы определенно обдумал его, учитывая, что стратегия охвата не доказала свою эффективность во многих проектах на протяжении многих лет. Подумайте об этом.
—
Я думаю, это все! Спасибо за чтение, дайте мне знать, что вы думаете об этом!
