Спасибо! Да, теперь формулировка про нишу звучит близко к тому, как мы сами это видим.
Только я бы предложил разделить несколько задач.
Наш инструмент не пытается доказать, что тесты достаточные или что лишних тестов нет. Он решает более прикладную задачу для нас и в частности для наших процессов: быстро показать, откуда начался impact, по каким компонентным связям он может подняться выше, какие проверки уже привязаны к этой зоне и где в затронутой цепочке вообще нет явного покрытия. Для нас это в некоторый момент стало максимально критично.
В текущей реализации это не coverage-анализ и не мутационный анализ. То есть отчёт отвечает на вопросы уровня дизайн-системы:
какой компонент/state изменился;
кто зависит от него напрямую и транзитивно;
какие unit/Paparazzi/android-тесты уже явно привязаны к этой зоне;
у каких затронутых компонентов нет Paparazzi/Android/unit/preview покрытия.
Мутационное тестирование действительно сильнее в другом вопросе: насколько существующие тесты чувствительны к изменению поведения. Но для нашего MR-сценария оно тяжелее и отвечает не совсем на тот же вопрос. Особенно в UI/design-system контексте, где часть ценности — не только «упал/не упал тест», а ещё «какие компоненты потенциально затронуты и куда смотреть ревьюеру/тестировщику/дизайнеру».
Поэтому я бы не противопоставлял эти подходы. Coverage/diff и mutation testing могут быть хорошими следующими слоями проверки качества тестов. А impact graph — это более дешёвый слой навигации по компонентной структуре и тестовому покрытию в каждом MR.
P.S. По поводу «разметчика» (текущий подход с разметкой тестов через @TestedComponent ). Есть фидбэк от разработчиков, которые подключаются к доработкам компонентов. Думаем над «автоматизацией» данного кейса.
И да, предложение дружить финтехами звучит отлично :)
Спасибо! Да, теперь формулировка про нишу звучит близко к тому, как мы сами это видим.
Только я бы предложил разделить несколько задач.
Наш инструмент не пытается доказать, что тесты достаточные или что лишних тестов нет. Он решает более прикладную задачу для нас и в частности для наших процессов: быстро показать, откуда начался impact, по каким компонентным связям он может подняться выше, какие проверки уже привязаны к этой зоне и где в затронутой цепочке вообще нет явного покрытия. Для нас это в некоторый момент стало максимально критично.
В текущей реализации это не coverage-анализ и не мутационный анализ. То есть отчёт отвечает на вопросы уровня дизайн-системы:
какой компонент/state изменился;
кто зависит от него напрямую и транзитивно;
какие unit/Paparazzi/android-тесты уже явно привязаны к этой зоне;
у каких затронутых компонентов нет Paparazzi/Android/unit/preview покрытия.
Мутационное тестирование действительно сильнее в другом вопросе: насколько существующие тесты чувствительны к изменению поведения. Но для нашего MR-сценария оно тяжелее и отвечает не совсем на тот же вопрос. Особенно в UI/design-system контексте, где часть ценности — не только «упал/не упал тест», а ещё «какие компоненты потенциально затронуты и куда смотреть ревьюеру/тестировщику/дизайнеру».
Поэтому я бы не противопоставлял эти подходы. Coverage/diff и mutation testing могут быть хорошими следующими слоями проверки качества тестов. А impact graph — это более дешёвый слой навигации по компонентной структуре и тестовому покрытию в каждом MR.
P.S. По поводу «разметчика» (текущий подход с разметкой тестов через
@TestedComponent). Есть фидбэк от разработчиков, которые подключаются к доработкам компонентов. Думаем над «автоматизацией» данного кейса.И да, предложение дружить финтехами звучит отлично :)