Привет всем! Я тут недавно наткнулась на очень интересную статистику: около 30% тестов в реальных проектах не ловят баги, даже когда они есть. И это меня, как QA-инженера, просто разрывает изнутри! Мы же пишем тесты, чтобы защитить код, но кто защитит нас от самих тестов? 😱
Вот я и хочу обсудить: как вы проверяете качество своих тестов? Не покрытие кода, а именно их способность находить ошибки. Я недавно начала экспериментировать с мутационным тестированием на Python (модуль mutmut), и это открыло мне глаза. Оно вносит мелкие изменения в код (мутации) и смотрит, упадут ли ваши тесты. Если не упали — значит, у вас дыра в проверках. Спойлер: у меня сначала было 40% «выживших» мутаций, и я чуть не расплакалась над своим же кодом! 😅
Вопрос к сообществу: кто-нибудь уже использует мутационное тестирование в продакшн-проектах? Насколько оно оправдывает затраты времени, особенно когда дедлайны горят? Или вы предпочитаете старый добрый coverage и ручное тестирование? Мне очень интересно услышать реальные кейсы, а не теоретические рассуждения из документации! 🔍
💡 1
Ну давай разберем. Твоя статистика про 30% — это еще цветочки, ягодки начинаются, когда эти «мертвые» тесты создают иллюзию безопасности. Я как раз недавно вычищал легаси-проект на Java, где coverage держался на 85%, но при этом половина ассертов была закомментирована «временно», а вторая половина проверяла, что метод не бросил исключение, а не то, что он вернул правильный результат. Мутационное тестирование там показало бы 60% выживших мутаций, и это был бы приговор.
Что касается продакшена — у нас это скорее инструмент для аудита, а не для каждой итерации. Запускать мутаторов на каждый коммит — это стрелять из пушки по воробьям, особенно когда билд и так собирается 15 минут. Но раз в спринт, перед крупным релизом или после рефакторинга — да, оно оправдывает себя. Особенно если у тебя есть модули, где цена ошибки высока: платежи, авторизация, расчеты. Только не забывай, что мутационное тестирование — это не замена code review, а его усилитель. Оно покажет дыры в логике тестов, но не объяснит, как их правильно закрыть. Так что да, полюбить его можно, но как сурового начальника, который приходит раз в месяц и показывает, где ты налажал.
👍 1
Слушай, а вот насчет «сурового начальника» — я, пожалуй, зайду с другой стороны. Согласен, что мутационное тестирование — это боль для CI, и запускать его на каждый коммит — мазохизм чистой воды. Но твой тезис про «иллюзию безопасности» меня зацепил, и тут я скорее не соглашусь с акцентом на «страшнее». Баг в коде — это конкретная, воспроизводимая проблема, которую юзер может найти в проде. А вот баг в тесте — это куда коварнее: он не стреляет, он молча разъедает уверенность команды в том, что вообще можно рефакторить легаси. Ты привел пример с 85% coverage и закомментированными ассертами — так это не баги в тестах, это отсутствие тестов как таковых, замаскированное под метрику.
Другое дело — когда у тебя есть нормальные, живые тесты, но они проверяют не то, что нужно. Вот тут мутационное тестирование реально раскрывается: оно бьет не по покрытию, а по поведению. Я как-то на React-проекте мутировал `useMemo` — просто убрал зависимости, и 70% тестов прошли, потому что все проверяли наличие DOM-ноды, а не актуальность данных. И вот это страшнее любого бага в проде, потому что прод-баг ты исправишь за вечер, а вот переписать тестовую стратегию модуля, который «работает» уже два года, — это спринт работы. Так что мутационное тестирование — не суровый начальник, а скорее честный аудитор, который приходит не ругать, а показать, где ты сам себя обманываешь. Другое дело, что к его выводам надо подходить с холодной головой и не пытаться закрыть 100% мутаций — иначе потратишь неделю на тесты ради тестов.
👍 1
