Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Много забавного поймали :)
Например, опечатки в assert-ах:
Еще находились кусочки кода, в тестах для которых вообще не покрыты граничные условия, при этом code coverage близился к 100%.
Была даже пара тестов которые при любом изменении тестируемого кода проходили ¯\_(ツ)_/¯
В целом, такие ошибки на большом и старом проекте будут всегда возникать, мутационные тесты помогут их выявлять и держать под контролем.
Но главное — мутационное тестирование поможем вам начать писать более качественные тесты прям со старта.
Например, опечатки в assert-ах:
assertCount(1, count($some_var)); //до php 7.2 спокойненько себе всегда проходила
assertTrue(true, $some_var);
Еще находились кусочки кода, в тестах для которых вообще не покрыты граничные условия, при этом code coverage близился к 100%.
Была даже пара тестов которые при любом изменении тестируемого кода проходили ¯\_(ツ)_/¯
В целом, такие ошибки на большом и старом проекте будут всегда возникать, мутационные тесты помогут их выявлять и держать под контролем.
Но главное — мутационное тестирование поможем вам начать писать более качественные тесты прям со старта.
Я больше чем уверен, что эти цифры приведены в качестве примера. Даже когда я ещё работал в Badoo (около 3 лет назад) было около 60 тысяч юнит тестов и они шли порядка 100 минут, если посчитать суммарно время выполнения всех из них (но при этом они выполнялись параллельно и проходили за пару минут). На первый взгляд может показаться, что там действительно нечего тестировать, но на самом деле вы видите только вершину айсберга и на деле кода в Badoo очень много и его нужно тестировать :).
Вы безусловно правы, в идеальных условиях именно столько должны бежать юниты. Но проект огромный, много тестов писалось на заре развития юнит тестирования, не самым оптимальным способом. Все это приводится в порядок, новый код пишется так чтобы тесты для него были быстрые и блестящие, но это процесс не быстрый.
Есть метрика, есть отчеты в разрезах команд, компонентов и прочего :)
Никто не относится к ним как к артефактам, мы ведем работу над их улучшением, я всего лишь говорю вам о том, что есть некий «багаж», который нужно разобрать. Мы вкладываем в это время и ресурсы, но не в ущерб остальным процессам.
Не-не, дискуссии это прекрасно. Никто и не говорит что решение X лучше Y. X — способ существовать сейчас, Y — светлое будущее достижение которого требует времени. К тому же, решение Х еще позволяет запускать функциональные и end-to-end тесты, которые нельзя сделать сильно быстрыми.
Никто не относится к ним как к артефактам, мы ведем работу над их улучшением, я всего лишь говорю вам о том, что есть некий «багаж», который нужно разобрать. Мы вкладываем в это время и ресурсы, но не в ущерб остальным процессам.
Не-не, дискуссии это прекрасно. Никто и не говорит что решение X лучше Y. X — способ существовать сейчас, Y — светлое будущее достижение которого требует времени. К тому же, решение Х еще позволяет запускать функциональные и end-to-end тесты, которые нельзя сделать сильно быстрыми.
Как уже написал youROCK выше, это всего лишь пример взятый из головы.
В Badoo по состоянию на сегодня 71 000 тестов (полгода назад было чуть больше 100 000), в результате оптимизаций и пересмотра мы немного уменьшили их количество, но сильно подтянули по скорости работы. Сейчас они пробегаю за 35-40 секунд на нашем тестовом облаке.
В Badoo по состоянию на сегодня 71 000 тестов (полгода назад было чуть больше 100 000), в результате оптимизаций и пересмотра мы немного уменьшили их количество, но сильно подтянули по скорости работы. Сейчас они пробегаю за 35-40 секунд на нашем тестовом облаке.
Скорость действительно впечатляет. Это только unit тесты, или среди них есть еще и функциональные, тесты, работающие с БД, http запросами? Расскажите по-подробней, пожалуйста.
И каковы основные приемы ускорения, кроме параллелизации?
И каковы основные приемы ускорения, кроме параллелизации?
Это только Unit-тесты.
Есть еще 19 000 функциональных, на облаке сейчас пробегают за 3-5 минут, но мы еще не брались за их оптимизации.
И примерно 6 300 end-to-end тестов, бегают около 10 минут сейчас, активно оптимизируем.
Грамотная параллелизация это 80% успеха, это намного сложнее чем кажется. Нужно правильно разбить сьют по тредам, эффективно чекаутить рабочие копии, разбираться с экстра длинными тест-кейсами, следить за равномерностью нагрузки машин клауда и прочие радости.
Для юнитов мы сделали еще несколько финтов.
Первое, запретили ходить в сеть на уровне кода, ибо раньше в юните совершенно случайно могли случаться походы в мемкэш или базы, в какие-либо демона. Сейчас любой поход в сеть внутри юнит теста заканчивается выбросом эксепшена и падением теста. Это сделало юниты сильно стабильнее, и ускорило, так как походы в сеть основной источник энтропии во времени прогона.
Второе, максимально облегчили изначально тяжелый базовый тест-кейс. Например исторически мы на tearDown чистили большой список классов со статик кэшами и синглтонами (которые еще остались со времен когда это было модно :)). Мы пересмотрели этот подход, перестали их чистить на каждый чих и просто наладили мониторинг за тестами — если тест оставляет за собой грязный контекст — мы это быстро обнаруживаем.
Есть еще 19 000 функциональных, на облаке сейчас пробегают за 3-5 минут, но мы еще не брались за их оптимизации.
И примерно 6 300 end-to-end тестов, бегают около 10 минут сейчас, активно оптимизируем.
Грамотная параллелизация это 80% успеха, это намного сложнее чем кажется. Нужно правильно разбить сьют по тредам, эффективно чекаутить рабочие копии, разбираться с экстра длинными тест-кейсами, следить за равномерностью нагрузки машин клауда и прочие радости.
Для юнитов мы сделали еще несколько финтов.
Первое, запретили ходить в сеть на уровне кода, ибо раньше в юните совершенно случайно могли случаться походы в мемкэш или базы, в какие-либо демона. Сейчас любой поход в сеть внутри юнит теста заканчивается выбросом эксепшена и падением теста. Это сделало юниты сильно стабильнее, и ускорило, так как походы в сеть основной источник энтропии во времени прогона.
Второе, максимально облегчили изначально тяжелый базовый тест-кейс. Например исторически мы на tearDown чистили большой список классов со статик кэшами и синглтонами (которые еще остались со времен когда это было модно :)). Мы пересмотрели этот подход, перестали их чистить на каждый чих и просто наладили мониторинг за тестами — если тест оставляет за собой грязный контекст — мы это быстро обнаруживаем.
Я не думаю, что основная архитектура параллельного запуска не особо изменилась. Я о ней писал статью: m.habr.com/ru/company/badoo/blog/220211
спасибо за статью.
1. Есть ли у вас новые какие-то мутаторы по сравнению с Infection? Если да, не хотите ли вы контрибьютнуть обратно?
2. Забираете ли вы к себе наши новые мутаторы, когда они добавляются в Infection?
Мы думаем о выделении набора мутаторов в отдельный package, что бы можно было их проще использовать всем, кому захочется, и что бы было возможно всем (а не только нам) их и саппортить / обновлять.
2. Забираете ли вы к себе наши новые мутаторы, когда они добавляются в Infection?
Мы думаем о выделении набора мутаторов в отдельный package, что бы можно было их проще использовать всем, кому захочется, и что бы было возможно всем (а не только нам) их и саппортить / обновлять.
1. Пока ничего нового не придумали :) Но если придумаем — обязательно законтрибьютим!
2. Я обновлял их только один раз, в текущем исполнении это немножко нудно, а текущий набор мутаторов нас устраивает
Это было бы круто! В таком исполнении мы бы просто подключили их через композер как зависимость и регулярно обновляли.
2. Я обновлял их только один раз, в текущем исполнении это немножко нудно, а текущий набор мутаторов нас устраивает
Это было бы круто! В таком исполнении мы бы просто подключили их через композер как зависимость и регулярно обновляли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мутационное тестирование в PHP: качественное измерение для code coverage