Home

Автор: Джил Зильберфельд (Gil Zilberfeld)
Оригинал статьи
Перевод: Ольга Алифанова

Хрупкие тесты.

При одной мысли о них нас тошнит, и это неспроста. Им нельзя доверять. И они стоят денег.

Начнем с доверия. У нас есть тесты, которые проверяют один и тот же код, срабатывают в большинстве случаев, но затем один билд из сотни падает. Затем мы прогоняем тесты еще раз, и они проходят успешно.

Ах, это эти тесты, ну значит, все в порядке. Нужно просто прогнать их еще раз. Однако доверие к остальным тестам начинает подрываться. Если эти тесты "обычно" срабатывают, можно ли доверять прочим тестам? Что, если они начнут падать – их надо будет просто прогнать еще раз, и все будет хорошо? Может, сделать это дважды, и все исправится?

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

А ведь есть еще и время. Возможно, повторный прогон – это ок, но затем вы спросите себя, это регулярное падение, или что-то новое? Не узнаешь, пока не проверишь. Логи, дебаг, повторный прогон, сравнение.

И после этого вы не находите ничего особенного и списываете все на "снова эти хрупкие тесты". Два часа вашего ценного времени в трубу.

Хрупкие тесты – не то, что мне нравится в мире, как вы уже поняли. Но знаете, что в них хуже всего?

Их имя.

Мы называем их хрупкими тестами. Но в реальности они вовсе не хрупкие. Хрупок код. Или дизайн. Или архитектура.

Конечно, мы видим падения в тестах. Это дымовая завеса. Пожар на самом деле ниже этажом. Беда редко в самих тестах.

И это проблема, потому что мы (опять!) сдвигаем ответственность за качество с разработчиков на тестировщиков.

Мне без разницы, кто должен это исправлять. Но пока мы считаем "хрупкие тесты" неотъемлемой частью своей жизни, мы приговариваем тестировщиков к трате кучи времени на разбирательства, что они сделали не так (хотя, возможно, все сделано верно) вместо того, чтобы разделить ответственность за качество с командой.

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

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

Если вы умны, то не будете избавляться от хрупких тестов, а исправите хрупкий код, который они проверяют.

И прекратите их так называть.

Обсудить в форуме