Что такое смоук-тестирование? Пять минут, которые решают, стоит ли тестировать дальше

Смоук-тест - это короткий поверхностный проход по тому, что сборка обязана уметь, прежде чем кто-то потратит на неё время. Запускается ли она. Может ли кто-нибудь войти. Отрисовывается ли главная страница. Сохраняется ли запись. Если хоть что-то из этого не работает, сборку отклоняют и дальше никто не смотрит, потому что всё последующее было бы тестированием сборки, которую не стоило тестировать вовсе.

Он намеренно не подробный. Подробность - дело остального набора тестов, и прогон его по сломанной сборке тратит день на то, чтобы сорока способами доказать, что вход не работает.

Откуда взялось название

Из железа, и история тут буквальная. Вы собираете плату, подаёте питание и смотрите, не пойдёт ли дым. Если пошёл дым, измерять что-либо бессмысленно: неисправность груба и очевидна, и плата отправляется обратно. Сантехники используют то же выражение для продувки труб дымом, чтобы найти утечки до того, как стены будут закрыты.

Софт позаимствовал термин по той же причине. Сборка, которая не может пустить пользователя внутрь, задымила, и правильная реакция - остановиться.

Чем смоук-тест не является

Три термина используют на стендапах как взаимозаменяемые, а это три разные вещи.

Смоук-тест

Стоит ли эту сборку вообще тестировать? Широкий и поверхностный, запускается первым, на каждой сборке

Регрессионный тест

Перестало ли работать то, что работало раньше? Глубокий и медленный, запускается, когда есть время

Санити-тест - третий: узкая проверка того, что конкретное исправление действительно работает, запускаемая после того, как изменение попало в сборку, а не перед началом тестирования. Смоук широкий и поверхностный; санити узкий и поверхностный; регрессия широкая и глубокая.

Практическая разница в том, что происходит при падении. Упавший регрессионный тест - это дефект, который надо завести. Упавший смоук-тест - это решение: эта сборка дальше не идёт.

Что в него входит

Правило, которое удерживает смоук-набор полезным: всё в нём должно быть тем, чей отказ делает дальнейшее тестирование бессмысленным. Список получается заметно короче, чем кажется сначала.

Типичный набор для веб-приложения:

1. Приложение запускается, и главная страница отвечает 200
2. Известный пользователь может войти
3. Основной список загружается и показывает данные
4. Одну запись можно создать и прочитать обратно
5. Вошедший пользователь может выйти

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

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

Когда он запускается и кто на него смотрит

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

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

Эта немедленность и есть большая часть пользы. Тот же дефект, найденный на день позже, стоит кому-то часа восстановления картины, прежде чем он вообще сможет начать.

Как написать первый

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

• Возьмите пять пунктов, а не пятьдесят. Если вы не можете обосновать, что отказ делает дальнейшее тестирование бессмысленным, это не смоук-проверка.
• Используйте известную учётную запись и известные данные. Смоук-тест, который зависит от того, что случайно оказалось в базе, будет падать по причинам, не имеющим отношения к сборке.
• Проверяйте наличие, а не правильность. «Итог счёта равен 45,00» относится к другому месту. «Страница счёта отрисовалась» относится сюда.
• Держитесь в пределах пяти минут. Как только он начнёт стоить дороже, кто-нибудь вынесет его из критического пути, и после этого он перестанет что-либо удерживать.
• Падайте громко. Красный конвейер, о котором никому не сообщили, - это зелёный конвейер с лишними шагами.

Когда он падает

Упавший смоук-тест - это не баг-репорт. Это сигнал, что баг-репорт нужен, и эти две вещи легко перепутать: «смоук-тест 3 упал» не говорит тому, кто возьмёт задачу, ничего о том, что произошло.

Ему нужно то же, что нужно любому дефекту: что ожидалось, что произошло вместо этого, в каком окружении и всё, что браузер или раннер записали в тот момент. Наше руководство о том, как написать баг-репорт, который починят, - это длинная версия, а его шаблон - файл, который можно отдать тому, кто разбирает очередь.

Для отказа, на который человек наткнулся руками, а не поймал конвейер, контекст - это как раз та часть, которая обычно теряется.

Коротко

Смоук-тест отвечает на один вопрос: стоит ли эта сборка чьего-либо времени? Пять проверок, запускаемых первыми и запускаемых всегда, и падение останавливает конвейер, а не наполняет трекер. Всё остальное, что вы хотите знать о сборке, - это вопросы, которые имеет смысл задавать только после того, как на этот ответили «да».