Что, если бы я сказал вам, что Люди Икс могут сделать вас лучшим тестером программного обеспечения? Что ж, они не могут, но их суперзлодей Уильям Страйкер может.

Эта статья посвящена тому, как улучшить ваши модульные тесты с помощью мутационного тестирования. Существует несколько фреймворков для тестирования мутаций, но фреймворк, о котором я буду говорить, называется Страйкер, удачно названный в честь суперзлодея из Людей Икс, который хочет убить всех мутантов. Я использую Stryker уже более двух лет, за эти два года я реализовал Stryker в трех крупных корпоративных проектах и ​​провел несколько презентаций по фреймворку.

Осторожность!

Я хочу начать эту статью с предупреждения, тестирование мутаций не для слабонервных. Сначала это утомительно, отнимает много времени и часто затягивает этап тестирования разработки, часто требуя от разработчиков писать еще больше модульных тестов. Зачем вообще возиться с этим? Потому что это надежный способ убедиться, что ваши модульные тесты действительно приносят пользу.

Каждый разработчик видел модульный тест, который отлично выглядит, но на самом деле ничего не тестирует или просто существует для обеспечения покрытия кода. Это тесты, которые дает тестирование на мутации. Это вишенка на вершине модульных тестов, выбор судьбы, любой тестировщик Rockstar не станет настоящей рок-звездой, если у него нет тестирования на мутации, проверяющего свои модульные тесты. Теперь, когда вас предупредили, давайте перейдем к деталям.

Что такое мутационное тестирование?

Простой ответ из одного предложения: тестирование на мутации - это тестирование ваших модульных тестов. Что это значит? Мутационное тестирование выполняется с помощью фреймворка, такого как Stryker, который мутирует или изменяет определенные части вашего кода и проверяет, не приводит ли эта мутация к сбою модульного теста. Если мутант вызывает сбой одного из ваших существующих модульных тестов, мутант считается «убитым». В конце тестирования мутаций создается отчет с полным списком убитых и выживших мутантов, аналогичный тому, что вы увидите в отчете о покрытии кода с помощью Jest или Jasmine.

Простой пример

Допустим, у вас есть код, который генерирует URL-адрес для приложения. Надеюсь, есть модульный тест, проверяющий этот URL-путь и гарантирующий, что он будет сгенерирован. Придет фреймворк тестирования мутаций и преобразует вашу конечную точку в нулевую или пустую строку. Что происходит с вашим модульным тестом? Если это не удается, значит, ваш тест достаточно умен, чтобы знать, каким должен быть URL, и мутант будет считаться убитым. Если ваш модульный тест не дает результатов, значит, ваш модульный тест не так хорош, как вы думали. В фреймворке мутант будет отмечен как выживший, и вам нужно будет вернуться к чертежной доске, чтобы написать лучший модульный тест. Ниже приведен пример того, что может сделать мутация строки:

String url = "deadpool.com"
goTo(url)
//mutated code
String url = ""
goTo(url)

Фреймворки мутационного тестирования

Stryker - это фреймворк для тестирования мутаций с открытым исходным кодом, который имеет очень активное сообщество разработчиков. Когда я начал использовать Stryker два года назад, фреймворк был доступен только для JavaScript, но с годами он продолжал расти и теперь доступен для JavaScript, TypeScript, Scala и C #. Он имеет инструмент командной строки, доступный для быстрой и простой настройки, и прекрасно работает с распространенными средами тестирования, такими как Jasmine и Jest. Я также использовал PIT Test для Java, концепция тестирования мутаций такая же, но фреймворк больше основан на консоли. Хотя каждая среда тестирования мутаций может немного отличаться, концепция остается той же, и важно просто начать ее использовать.

Плюсы и минусы тестирования мутаций

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

Pro

  • Модульные тесты более высокого качества
  • Больше не нужно писать бессмысленные тесты, которые служат только для увеличения метрики (например, покрытия кода)
  • Больше уверенности в том, что ваше приложение полностью протестировано
  • Меньше производственных дефектов
  • Выявлено больше ошибок
  • Возможность для разработчиков мгновенно получать отзывы о качестве своих модульных тестов.
  • Stryker работает параллельно, поэтому он может работать очень быстро, если ресурсы доступны.

Con’s

  • Добавляет дополнительный шаг в цикл разработки
  • Работа с большой кодовой базой на машине с четырьмя или менее ядрами может занять более часа.
  • Может быть сложно определить конфигурацию, если конфигурация, созданная с помощью интерфейса командной строки, не работает для вашего проекта.

Заключение

Мутационное тестирование все еще кажется редкостью среди разработчиков, но, надеюсь, эта статья вдохновила всех читающих разработчиков попробовать. Настройка может быть медленной, и первым мутантам может потребоваться много времени, чтобы убить, но чем больше мутантов будет убито, тем быстрее станет процесс. Если не считать Wolverine, предлагающего обучение модульному тестированию, Stryker и тестирование мутаций максимально приближены к Людям Икс, улучшающим ваши модульные тесты.