Стратегия тестирования

Не о том, как написать тест — для этого есть страница о тестировании во Flutter, — а о том, зачем нужен набор тестов целиком, куда имеет смысл вкладывать усилия и как сделать так, чтобы он окупался.

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

Что нужно понимать

• Что причинит больше всего вреда, если сломается, и покрыто ли оно
• Что каждый уровень тестов ловит такого, чего не ловят остальные
• Что упавший тест должен сообщить — сразу, без разбирательств
• Во что обходится набор тестов: время, поддержка и те изменения, от которых он отговаривает
• Какие риски дешевле закрыть мониторингом, а не тестами

Ключевые темы

Форма

• Пирамида и почему это аргумент про стоимость, а не правило
• Внизу быстрые и многочисленные, наверху медленные и редкие
• Где между клиентом и сервером находятся контрактные тесты
• Ручное тестирование как осознанный выбор для отдельных вещей

Выбор

• От рисков: вероятность, умноженная на ущерб, а не процент покрытия
• Тестирование поведения на границе, а не реализации внутри неё
• От багов: каждый баг на проде оставляет после себя тест
• Что не тестировать: сгенерированный код, поведение фреймворка, мелочи

Доверие

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

Экономика

• Длительность прогона и точка, после которой его перестают запускать
• Стоимость поддержки, когда тесты слишком много знают о реализации
• Покрытие как диагностика, но никогда как цель
• Удаление тестов, которые больше не окупаются

В пайплайне

• Что запускается на каждый коммит, на каждый pull request, ночью
• Параллельный и выборочный запуск
• Блокировка релиза по нужному подмножеству тестов

Уровни

Уровень	Как это выглядит
Junior	Пишет тесты на тот код, который просят покрыть.
Middle	Осознанно выбирает уровень, тестирует поведение на границах, на каждый баг добавляет регрессионный тест.
Senior	Задаёт стратегию для кодовой базы: что покрыто, что нет и почему, держит набор тестов быстрым и заслуживающим доверия, понимает, что мониторинг закрывает лучше тестов.

Практика

Для начала

• Покройте критичный сценарий Найдите тот единственный сценарий, который не должен ломаться никогда, и убедитесь, что он протестирован от начала до конца.

• Превратите баг в тест Возьмите последний баг с прода и напишите тест, который бы его поймал.

• Замерьте прогон Измерьте, сколько времени идут тесты, и найдите, что занимает больше всего.

Глубже

• Сопоставьте риски и покрытие Выпишите, что причинит больше всего вреда при поломке, и проверьте, чем именно каждый пункт покрыт. Закройте пробелы.

• Удалите тесты Найдите тесты, которые проверяют только реализацию, и удалите их, обосновав решение.

• Разделите пайплайн Отделите быстрые проверки на каждый коммит от медленных ночных и выберите границу осознанно.

Проверьте себя

• Что в вашем продукте нанесёт больше всего ущерба, если сломается, и протестировано ли оно?
• Какая доля падений ваших тестов — настоящие баги?
• Сколько должен идти прогон, чтобы его начали избегать?
• Какие тесты ломаются при рефакторинге, который не менял поведение?
• Что вы сознательно не тестируете и сможете ли это защитить?
• Какие риски в вашем приложении лучше ловятся мониторингом, а не тестами?

Материалы

• Test Desiderata — двенадцать свойств хорошего теста от Кента Бека и главная мысль: они конфликтуют друг с другом. Лучшая из существующих опор для таких решений.
• Testing overview — уровни тестирования во Flutter и граница, за которой каждый из них перестаёт видеть проблемы.
• Google Testing Blog — особенно серия Testing on the Toilet: коротко, конкретно и в основном про здравый смысл, а не про технику.
• Software Engineering at Google, chapter 11 — тестирование в больших масштабах, бесплатно онлайн. Сильная глава о том, почему тесты обязаны быть быстрыми и детерминированными, иначе они ничего не стоят.
• The Practical Test Pyramid — подробный разбор от Хэма Вокке, включая контрактное тестирование между сервисами.