Pull to refresh
35
0
Максим Рафалко @borNfree

Разработчик (PHP, JS)

попробуйте прочитать мой пост (автора Infection) про МТ на хабре habr.com/ru/post/334394

Хоть посту и пару лет, но суть отражается и всё +- актуально
Сугубо ради интереса — сюда смогли отписать, а в issues — нет? Почему?
1. Есть ли у вас новые какие-то мутаторы по сравнению с Infection? Если да, не хотите ли вы контрибьютнуть обратно?
2. Забираете ли вы к себе наши новые мутаторы, когда они добавляются в Infection?

Мы думаем о выделении набора мутаторов в отдельный package, что бы можно было их проще использовать всем, кому захочется, и что бы было возможно всем (а не только нам) их и саппортить / обновлять.
Скорость действительно впечатляет. Это только unit тесты, или среди них есть еще и функциональные, тесты, работающие с БД, http запросами? Расскажите по-подробней, пожалуйста.

И каковы основные приемы ускорения, кроме параллелизации?
А что используете для мутационного тестирования?
Из вашего комментария не совсем понял, хорошо это или плохо?

Но а целом да, не упоминал специально.
А сколько у вас занимает МТ для вашего проекта?
Могли бы добавить в билд с опцией `--min-covered-msi`.

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

Самая основная, это запуск *только тех тестов, которые покрывают мутируемую строку*.

Это означает, что для Мутации X вам потребуется запуск не 500 тестов, а только Y из них (1,2, 5 — сколько получится). Более того, следующий шаг, это запуск сначала самых быстрых тестов, из тех что покрывают строку.

В целом, это кардинально снижает время, затраченное на мутационное тестирование.

Не знаю, может стоит написать Часть 2 про разные методики улучшения производительности, и как МТ устроено внутри?
Скажите, пробовали ли вы Infection там, где пробовали Humbug? Интересна разница на «живых примерах».

Буду благодарен за любые полезные комментарии по этому поводу.
Вы удивитесь, попробуя даже для вашего pet-project мутационное тестирование.
Тут дело не в крутости и сложности исходного кода, а в эффективности юнит тестов. А они то бывают плохими даже для простого кода.
Насколько я понял, чтобы использовать Infection, код должен быть написан в соответствии с типизацией php7?


Нет, это не обязательно. Просто строгая типизация уменьшает количество сгенерированных мутантов (как в примере про return type).

А так любой код может быть мутирован, с тайпхинтами или нет.
Хорошая идея, подумаю о добавлении этой фичи :)
Пока это невозможно, т.к. надо хранить где-то значения.
Из того что я знаю: у нас на работе ребята на митапе рассказывали, что используют на многих новых проектах, причем выставляя на билдах уровень в 100%. Но там Ruby и МФ — Mutant, возможно, он позволяет регистрировать false-positives и упомянутые в статье идентичный мутации.

Из опенсорса, @Ocramius использует в некоторых библиотеках МТ.
За вас она ничего не определяет, она пытается понизить модификатор доступа метода, и, если при этом тесты не падают, значит есть вероятность, что метод зря имеет такой уровень доступа. Такую мутацию надо проанализировать и либо дописать тест, либо сделать соответствующие изменения в коде.

Как говорят умные люди, любой `public` или `protected`метод — это ваш ребенок. Как только вы его написали, вы обязаны следить за ним и за его Backward Compatibility. Особенно, это касается Open Source библиотек, классы которых вы можете наследовать.

Пример из реального проекта: в базовом классе был `protected` метод, который переопределялся в дочерних классах. В результате рефакторинга иерархия классов изменилась, и из базового класса данный метод был удален, оставшись только в одном дочернем. Но модификатор доступа изменить забыли, т.е. он остался `protected`. Мутационное тестирование находит такие проблемы.
я именно про Encore и говорю, поддержка TypeScript была вмержена 5 дней назад
Стоит отметить, что релизнута была поддержка TypeScript, что делает этот интсрумент еще более интересным.
Еще краудфандинговая компания есть у автора PHPStan — https://www.patreon.com/phpstan
Кем не воспринимается? Значит ли это, что тесты должны быть в любой библиотеке, просто «шоб було»?


Не воспринимается разработчиками. Если я вижу выбор среди нескольких бандлов/модулей, не последнее место будет занимать критерий выбора по наличию test suite.

Да что тут говорить, когда делаешь PR тебя в большинстве случаях попросят добавить и тесты, хотябы как самый свежий пример — изменение в этом плане политики в репозитории Yii фреймворка.

А кто будет гарантировать качество самих тестов? Всегда ли это решение разумно и обосновано?


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

Еще раз подчеркну, тесты гарантируют вам что после рефакторинга ваш код работает так, как вы это задумывали до него. Меньше траты времени на поддержку -> меньше багов -> более стабильный код
добавил в статью еще альтернативный вариант
по степени владения языком


надеюсь вы про PHP ;)

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity