1. Есть ли у вас новые какие-то мутаторы по сравнению с Infection? Если да, не хотите ли вы контрибьютнуть обратно?
2. Забираете ли вы к себе наши новые мутаторы, когда они добавляются в Infection?
Мы думаем о выделении набора мутаторов в отдельный package, что бы можно было их проще использовать всем, кому захочется, и что бы было возможно всем (а не только нам) их и саппортить / обновлять.
Скорость действительно впечатляет. Это только unit тесты, или среди них есть еще и функциональные, тесты, работающие с БД, http запросами? Расскажите по-подробней, пожалуйста.
И каковы основные приемы ускорения, кроме параллелизации?
Вы немного заблуждаетесь.
Я не описал этот момент в статье, но у мутационного тестирования есть свои методики увеличения скорости работы.
Самая основная, это запуск *только тех тестов, которые покрывают мутируемую строку*.
Это означает, что для Мутации X вам потребуется запуск не 500 тестов, а только Y из них (1,2, 5 — сколько получится). Более того, следующий шаг, это запуск сначала самых быстрых тестов, из тех что покрывают строку.
В целом, это кардинально снижает время, затраченное на мутационное тестирование.
Не знаю, может стоит написать Часть 2 про разные методики улучшения производительности, и как МТ устроено внутри?
Вы удивитесь, попробуя даже для вашего pet-project мутационное тестирование.
Тут дело не в крутости и сложности исходного кода, а в эффективности юнит тестов. А они то бывают плохими даже для простого кода.
Из того что я знаю: у нас на работе ребята на митапе рассказывали, что используют на многих новых проектах, причем выставляя на билдах уровень в 100%. Но там Ruby и МФ — Mutant, возможно, он позволяет регистрировать false-positives и упомянутые в статье идентичный мутации.
Из опенсорса, @Ocramius использует в некоторых библиотеках МТ.
За вас она ничего не определяет, она пытается понизить модификатор доступа метода, и, если при этом тесты не падают, значит есть вероятность, что метод зря имеет такой уровень доступа. Такую мутацию надо проанализировать и либо дописать тест, либо сделать соответствующие изменения в коде.
Как говорят умные люди, любой `public` или `protected`метод — это ваш ребенок. Как только вы его написали, вы обязаны следить за ним и за его Backward Compatibility. Особенно, это касается Open Source библиотек, классы которых вы можете наследовать.
Пример из реального проекта: в базовом классе был `protected` метод, который переопределялся в дочерних классах. В результате рефакторинга иерархия классов изменилась, и из базового класса данный метод был удален, оставшись только в одном дочернем. Но модификатор доступа изменить забыли, т.е. он остался `protected`. Мутационное тестирование находит такие проблемы.
Кем не воспринимается? Значит ли это, что тесты должны быть в любой библиотеке, просто «шоб було»?
Не воспринимается разработчиками. Если я вижу выбор среди нескольких бандлов/модулей, не последнее место будет занимать критерий выбора по наличию test suite.
Да что тут говорить, когда делаешь PR тебя в большинстве случаях попросят добавить и тесты, хотябы как самый свежий пример — изменение в этом плане политики в репозитории Yii фреймворка.
А кто будет гарантировать качество самих тестов? Всегда ли это решение разумно и обосновано?
Мне кажется, вы придираетесь к словами. Когда вы пишите тесты, вы часто находите ошибки в своем коде (если пишите их после написания кода). Либо тесты помогают вам изначально выстроить более лучшую архитектуру ваших классов, если вы пишите тесты до написания кода. Естественно могут быть ошибки и в тестах, это очевидно.
Еще раз подчеркну, тесты гарантируют вам что после рефакторинга ваш код работает так, как вы это задумывали до него. Меньше траты времени на поддержку -> меньше багов -> более стабильный код
Хоть посту и пару лет, но суть отражается и всё +- актуально
2. Забираете ли вы к себе наши новые мутаторы, когда они добавляются в Infection?
Мы думаем о выделении набора мутаторов в отдельный package, что бы можно было их проще использовать всем, кому захочется, и что бы было возможно всем (а не только нам) их и саппортить / обновлять.
И каковы основные приемы ускорения, кроме параллелизации?
Но а целом да, не упоминал специально.
Могли бы добавить в билд с опцией `--min-covered-msi`.
Данный показатель позволит не снижать качество существующих и новых тестов. Но если писать новые не будете, билд падать не будет.
Я не описал этот момент в статье, но у мутационного тестирования есть свои методики увеличения скорости работы.
Самая основная, это запуск *только тех тестов, которые покрывают мутируемую строку*.
Это означает, что для Мутации X вам потребуется запуск не 500 тестов, а только Y из них (1,2, 5 — сколько получится). Более того, следующий шаг, это запуск сначала самых быстрых тестов, из тех что покрывают строку.
В целом, это кардинально снижает время, затраченное на мутационное тестирование.
Не знаю, может стоит написать Часть 2 про разные методики улучшения производительности, и как МТ устроено внутри?
Буду благодарен за любые полезные комментарии по этому поводу.
Тут дело не в крутости и сложности исходного кода, а в эффективности юнит тестов. А они то бывают плохими даже для простого кода.
Нет, это не обязательно. Просто строгая типизация уменьшает количество сгенерированных мутантов (как в примере про return type).
А так любой код может быть мутирован, с тайпхинтами или нет.
Пока это невозможно, т.к. надо хранить где-то значения.
Из опенсорса, @Ocramius использует в некоторых библиотеках МТ.
Как говорят умные люди, любой `public` или `protected`метод — это ваш ребенок. Как только вы его написали, вы обязаны следить за ним и за его Backward Compatibility. Особенно, это касается Open Source библиотек, классы которых вы можете наследовать.
Пример из реального проекта: в базовом классе был `protected` метод, который переопределялся в дочерних классах. В результате рефакторинга иерархия классов изменилась, и из базового класса данный метод был удален, оставшись только в одном дочернем. Но модификатор доступа изменить забыли, т.е. он остался `protected`. Мутационное тестирование находит такие проблемы.
Не воспринимается разработчиками. Если я вижу выбор среди нескольких бандлов/модулей, не последнее место будет занимать критерий выбора по наличию test suite.
Да что тут говорить, когда делаешь PR тебя в большинстве случаях попросят добавить и тесты, хотябы как самый свежий пример — изменение в этом плане политики в репозитории Yii фреймворка.
Мне кажется, вы придираетесь к словами. Когда вы пишите тесты, вы часто находите ошибки в своем коде (если пишите их после написания кода). Либо тесты помогают вам изначально выстроить более лучшую архитектуру ваших классов, если вы пишите тесты до написания кода. Естественно могут быть ошибки и в тестах, это очевидно.
Еще раз подчеркну, тесты гарантируют вам что после рефакторинга ваш код работает так, как вы это задумывали до него. Меньше траты времени на поддержку -> меньше багов -> более стабильный код
надеюсь вы про PHP ;)