Комментарии 9
Очень круто, реально. Дано внедрили? И есть ли фидбек от длительного использования, как с точки зрения удобства команд, так и с точки зрения эффективности написания кода? Давно задумывался о мутационном тестировании, но всегда останавливало то, что я не сторонник вообще большой степени покрытия кода тестами. По сути, MSI 100% означает что 100% логики приложения сдублировано в тестах и каждая особенность реализации отражена в тестах. И я считаю это вредным, в плане возрастающей цены поддержки. Далее, это значит что любой коммит всегда будет менять и саму программу и тесты. Т.е. программист просто пойдёт и напишет точно эту же логику ещё раз в тестах. В принципе извращённым вариантом этого является копипаст функции в тесты и сверка резлуьтатов копипасты и основного кода на всех путях исполнения. Я всегда считал полезным тот тест, который условно "выборочно" проверяет, что-то типа проверки части деталей из партии.
Спасибо!)
С момента появления МТ у нас, прошел уже практически год, но я бы не сказал, что мы уже совсем-совсем всё внедрили. Периодически все равно что-то допиливаем.
Команд у нас много и конечно мы имеем какой-то точечный фидбек, но как по мне, он все еще недостаточно полный.
Есть команды, которые еще не используют на полную мутационное тестирование, есть команды, где мутационное тестирование уже внедрено в процессы связанные с качеством, таких кстати большинство. Поэтому мы (наша команда) смотрим на косвенные признаки и понимаем как идут дела:
- Смотрим статистику - MSI у сервисов в основном растет (еще бы, ведь его целенаправленно повышают));
- Количество вопросов и фиче-реквестов в профильных чатиках тоже растет;
- Ну и на продуктовых метриках видим, что участники команд активно пользуются внутренними инструментами, причем с каждым днем все активнее.
Как-то так. То что командам/отдельным людям не нравится, выносится на обсуждение и превращается в таски :).
По сути, MSI 100% означает что 100% логики приложения сдублировано в
тестах и каждая особенность реализации отражена в тестах. И я считаю это
вредным, в плане возрастающей цены поддержки. Далее, это значит что
любой коммит всегда будет менять и саму программу и тесты. Т.е.
программист просто пойдёт и напишет точно эту же логику ещё раз в
тестах. В принципе извращённым вариантом этого является копипаст функции
в тесты и сверка резлуьтатов копипасты и основного кода на всех путях
исполнения. Я всегда считал полезным тот тест, который условно
"выборочно" проверяет, что-то типа проверки части деталей из партии.
Это достаточно холиварная тема на самом деле.
Да, поддерживать тесты на уровне становится дороже, это правда. То, что изменение логики влечет за собой изменение и тестов, тоже имеет место быть, и кстати как по мне, то это хороший признак, потому что тесты заставляют тебя держать контракт и помогают ориентироваться в изменениях логики, если ты например новый разработчик, или просто давно не контрибьютил в сервис и все позабыл.
Не соглашусь только по поводу того, что в тестах прямо-таки повторяется логика). Мутационное тестирование не заставляет повторять логику в тестах, а в основном подсвечивает не очень качественные проверки и места для рефакторинга. Это прям львиная доля мутантов из отчетов, которые довелось посмотреть. Ну и конечно же к 100% стремиться - это прям идеально, но мы у себя определили планку в 75% MSI именно потому, что часть проверок может не представлять ценности, такое можно либо скипнуть, либо еще что-то. В этом плане есть некая гибкость конечно же.
Интересно было бы почитать ещё про тестирование кода более подробно, и возможно, реализацию АТ, если они есть.
Прям очень интересно, спасибо! Пойду смотреть завтра, что есть под TypeScript и что оно даст у нас на проекте. Отдельно интересно про тестирование в React компонентах (больная тема).
У кого-то есть опыт?
Очень интересная статья. Конечно пока сам не попробую останется какое-то ощущение избыточности подхода
И такой вопрос: У вас экспертиза качества только тесты (юнит/интеграционные) или что-то ещё есть?
Мутационное тестирование: опыт внедрения на 1500 сервисов