Полный перебор комбинаций feature flags делает CI неприемлемым. Как сократить набор, сохранив проверку взаимодействий?
Примените комбинаторное тестирование, обычно начиная с покрытия всех пар значений (pairwise testing). Оно выбирает ограниченное число конфигураций, в которых каждая пара значений feature flags встречается хотя бы один раз, поэтому снижает объём прогона без полного перебора.
Это не гарантирует обнаружение ошибок, зависящих от трёх и более flags. Критичные комбинации нужно добавлять отдельно, а невозможные сочетания исключать из модели.
Подход появился как ответ на рост числа конфигураций, параметров и вариантов поведения. Если каждый параметр имеет несколько значений, полный перебор растёт экспоненциально и быстро становится слишком дорогим для регулярного тестирования.
Практика показала, что многие дефекты вызываются взаимодействием небольшого числа факторов. Поэтому тестирование всех пар или небольших сочетаний часто даёт полезный компромисс между покрытием и стоимостью.
Пусть в системе есть несколько независимых feature flags. Полный перебор их состояний проверяет все комбинации, но число запусков быстро увеличивается, замедляя CI и усложняя анализ результатов.
Проверка только одной конфигурации тоже опасна: отдельные flags могут работать корректно, но конфликтовать при совместном включении. Неверно выбранное сокращение набора создаёт ложное ощущение покрытия и может пропустить дефект взаимодействия.
Сначала задайте модель тестирования: flags, допустимые значения, зависимости между ними и запрещённые сочетания. Затем сгенерируйте набор конфигураций, покрывающий каждую допустимую пару значений хотя бы один раз.
Например, если два flags могут быть включены или выключены, pairwise-набор должен содержать варианты, где встречаются пары «включён–включён», «включён–выключен», «выключен–включён» и «выключен–выключен» для каждой пары flags. Конкретные конфигурации при этом могут одновременно покрывать несколько таких пар.
Перед запуском нужно добавить обязательные сценарии вручную: минимальную конфигурацию, конфигурацию по умолчанию, полностью включённый новый функционал, старое поведение и известные рискованные сочетания. Невозможные комбинации следует описать как ограничения, иначе генератор создаст недостижимые или бессмысленные тесты.
Pairwise подходит для большинства взаимодействий с невысокой степенью зависимости. Для критичных систем можно использовать покрытие троек или более высоких сочетаний (t-wise testing), но стоимость набора возрастёт.
Важно разделять проверку логики flags и полноценные пользовательские сценарии. Не обязательно прогонять весь end-to-end-набор на каждой конфигурации: дорогие сценарии можно оставить для рискованных комбинаций, а остальные взаимодействия проверять на более низком уровне.
В продукте четыре feature flags, каждый имеет два состояния. Полный перебор требует 16 конфигураций для одного набора сценариев. Команда рассматривала два варианта: проверять только конфигурацию по умолчанию или запускать все варианты.
Первый вариант был быстрым, но не проверял конфликты между flags. Второй давал максимальное покрытие, однако заметно увеличивал время CI и количество результатов, которые нужно анализировать.
Выбрали pairwise-набор, дополненный конфигурациями по умолчанию, полностью включённым новым поведением и несколькими бизнес-критичными сочетаниями. Такой подход уменьшил число запусков, сохранил проверку всех пар взаимодействий и оставил возможность отдельно тестировать сценарии, для которых риск ошибок выше.
Нет. Pairwise обнаруживает проблемы, зависящие от пар факторов, но может пропустить ошибку, возникающую только при одновременном сочетании трёх или более flags. Для таких областей применяют t-wise-покрытие или явно добавляют известные критичные комбинации.
Их нужно учитывать в модели ограничений. Например, если новый режим доступен только при включённом базовом функционале, конфигурация с выключенным базовым flag должна быть исключена или проверяться как отдельный негативный сценарий. Иначе набор будет содержать недостижимые состояния, а заявленное покрытие окажется формальным.
Pairwise определяет комбинации конфигураций, но не качество самих проверок. Он не гарантирует, что каждый важный пользовательский поток, переход состояния или негативный случай проверен в выбранной конфигурации. Поэтому комбинаторное покрытие должно дополнять функциональные, интеграционные и end-to-end-тесты, а не подменять их.