Привет! Спасибо за комментарий! Действительно я несколько упрощал и говорил о не-юнит-тестах как об одном целом. На самом деле действительно не все так просто и есть немало «оттенков серого». Кажется, на пирамиде тестирования можно однозначно положить только UI-тесты наверх, и Unit-тесты вниз, а вот в серединке есть разные варианты и вариаций там много. Но смысл один — чем выше по пирамиде тем больше частей приложения тестируется вместе и тем медленее/дороже/более хрупкими эти тесты становятся.
Ох, друзья, давайте мы филологические споры будем вести в личке.
Комментарии созданы не для того, чтобы меряться знаниями в орфографии и пунктуации, а чтобы обсуждать предмет статьи.
Я думал, что за годы проведенные на хабре все уже усвоили этот принцип :)
1. Пока ничего нового не придумали :) Но если придумаем — обязательно законтрибьютим!
2. Я обновлял их только один раз, в текущем исполнении это немножко нудно, а текущий набор мутаторов нас устраивает
Это было бы круто! В таком исполнении мы бы просто подключили их через композер как зависимость и регулярно обновляли.
Есть метрика, есть отчеты в разрезах команд, компонентов и прочего :)
Никто не относится к ним как к артефактам, мы ведем работу над их улучшением, я всего лишь говорю вам о том, что есть некий «багаж», который нужно разобрать. Мы вкладываем в это время и ресурсы, но не в ущерб остальным процессам.
Не-не, дискуссии это прекрасно. Никто и не говорит что решение X лучше Y. X — способ существовать сейчас, Y — светлое будущее достижение которого требует времени. К тому же, решение Х еще позволяет запускать функциональные и end-to-end тесты, которые нельзя сделать сильно быстрыми.
Все так. Около 2 часов полный прогон занимает. Поэтому мы считаем этот отчет ночью.
А в течении дня считаем только для branch diff и сравниваем с мастером (который рассчитали ночью)
Вы безусловно правы, в идеальных условиях именно столько должны бежать юниты. Но проект огромный, много тестов писалось на заре развития юнит тестирования, не самым оптимальным способом. Все это приводится в порядок, новый код пишется так чтобы тесты для него были быстрые и блестящие, но это процесс не быстрый.
Это только Unit-тесты.
Есть еще 19 000 функциональных, на облаке сейчас пробегают за 3-5 минут, но мы еще не брались за их оптимизации.
И примерно 6 300 end-to-end тестов, бегают около 10 минут сейчас, активно оптимизируем.
Грамотная параллелизация это 80% успеха, это намного сложнее чем кажется. Нужно правильно разбить сьют по тредам, эффективно чекаутить рабочие копии, разбираться с экстра длинными тест-кейсами, следить за равномерностью нагрузки машин клауда и прочие радости.
Для юнитов мы сделали еще несколько финтов.
Первое, запретили ходить в сеть на уровне кода, ибо раньше в юните совершенно случайно могли случаться походы в мемкэш или базы, в какие-либо демона. Сейчас любой поход в сеть внутри юнит теста заканчивается выбросом эксепшена и падением теста. Это сделало юниты сильно стабильнее, и ускорило, так как походы в сеть основной источник энтропии во времени прогона.
Второе, максимально облегчили изначально тяжелый базовый тест-кейс. Например исторически мы на tearDown чистили большой список классов со статик кэшами и синглтонами (которые еще остались со времен когда это было модно :)). Мы пересмотрели этот подход, перестали их чистить на каждый чих и просто наладили мониторинг за тестами — если тест оставляет за собой грязный контекст — мы это быстро обнаруживаем.
Как уже написал youROCK выше, это всего лишь пример взятый из головы.
В Badoo по состоянию на сегодня 71 000 тестов (полгода назад было чуть больше 100 000), в результате оптимизаций и пересмотра мы немного уменьшили их количество, но сильно подтянули по скорости работы. Сейчас они пробегаю за 35-40 секунд на нашем тестовом облаке.
assertCount(1, count($some_var)); //до php 7.2 спокойненько себе всегда проходила
assertTrue(true, $some_var);
Еще находились кусочки кода, в тестах для которых вообще не покрыты граничные условия, при этом code coverage близился к 100%.
Была даже пара тестов которые при любом изменении тестируемого кода проходили ¯\_(ツ)_/¯
В целом, такие ошибки на большом и старом проекте будут всегда возникать, мутационные тесты помогут их выявлять и держать под контролем.
Но главное — мутационное тестирование поможем вам начать писать более качественные тесты прям со старта.
Проблема в том, как Infection модифицирует файл. Он делает перехват инклюдов через stream_wrapper_register(), и подменяет на лету заинклюженный файл на файл с мутировавшим кодом. По-сути SoftMock действуют так же, просто через другой механизм.
В результате, подружить их друг с другом довольно сложно. Это возможно, но пришлось бы очень сильно влезть в код Infection.
Привет, спасибо за вопрос.
Если кратко, AspectMock умеет не все что нам было нужно.
Чтобы не пересказывать детали в комментарии — приведу статья, где мы подробно рассказывали зачем нам вообще понадобились софт моки habr.com/ru/company/badoo/blog/279617
Очень быстро разобрали. Мы попробуем добавить еще, но тогда в нашей кафешке может быть тесновато. Плюс у некоторого количества людей поменяются планы и места освободятся. Вообще посматривайте, начиная со след. недели, места могут появиться. Ну уж если совсем не повезет — будет трансляция :)
Я имел ввиду не клиентов кластера, а непосредственно сами машинки кластера. Обычно кластер размазанный по разным ДЦ начинает лагать от сетевых задержек между нодами из разных ДЦ. Не скажу про Cassandra, но на мускуле весьма острая проблема. Было собственно интересно, есть ли у вас проблемы и как вы их решали.
Привет! У меня вопросы по Cassandra. Будет ли ваше решение в opensource? Сравнивали с новомодным ClickHouse? Кластер Cassandra внутри одного ДЦ? Если нет то как решали проблему линка между ДЦ?
Спасибо.
Комментарии созданы не для того, чтобы меряться знаниями в орфографии и пунктуации, а чтобы обсуждать предмет статьи.
Я думал, что за годы проведенные на хабре все уже усвоили этот принцип :)
Я думаю ребята выслушают и подскажут :)
github.com/beerphp/spb
Нам пока по силам попробовать собрать такой формат только в Москве :(
2. Я обновлял их только один раз, в текущем исполнении это немножко нудно, а текущий набор мутаторов нас устраивает
Это было бы круто! В таком исполнении мы бы просто подключили их через композер как зависимость и регулярно обновляли.
Никто не относится к ним как к артефактам, мы ведем работу над их улучшением, я всего лишь говорю вам о том, что есть некий «багаж», который нужно разобрать. Мы вкладываем в это время и ресурсы, но не в ущерб остальным процессам.
Не-не, дискуссии это прекрасно. Никто и не говорит что решение X лучше Y. X — способ существовать сейчас, Y — светлое будущее достижение которого требует времени. К тому же, решение Х еще позволяет запускать функциональные и end-to-end тесты, которые нельзя сделать сильно быстрыми.
А в течении дня считаем только для branch diff и сравниваем с мастером (который рассчитали ночью)
Есть еще 19 000 функциональных, на облаке сейчас пробегают за 3-5 минут, но мы еще не брались за их оптимизации.
И примерно 6 300 end-to-end тестов, бегают около 10 минут сейчас, активно оптимизируем.
Грамотная параллелизация это 80% успеха, это намного сложнее чем кажется. Нужно правильно разбить сьют по тредам, эффективно чекаутить рабочие копии, разбираться с экстра длинными тест-кейсами, следить за равномерностью нагрузки машин клауда и прочие радости.
Для юнитов мы сделали еще несколько финтов.
Первое, запретили ходить в сеть на уровне кода, ибо раньше в юните совершенно случайно могли случаться походы в мемкэш или базы, в какие-либо демона. Сейчас любой поход в сеть внутри юнит теста заканчивается выбросом эксепшена и падением теста. Это сделало юниты сильно стабильнее, и ускорило, так как походы в сеть основной источник энтропии во времени прогона.
Второе, максимально облегчили изначально тяжелый базовый тест-кейс. Например исторически мы на tearDown чистили большой список классов со статик кэшами и синглтонами (которые еще остались со времен когда это было модно :)). Мы пересмотрели этот подход, перестали их чистить на каждый чих и просто наладили мониторинг за тестами — если тест оставляет за собой грязный контекст — мы это быстро обнаруживаем.
В Badoo по состоянию на сегодня 71 000 тестов (полгода назад было чуть больше 100 000), в результате оптимизаций и пересмотра мы немного уменьшили их количество, но сильно подтянули по скорости работы. Сейчас они пробегаю за 35-40 секунд на нашем тестовом облаке.
Это ресурсоемко, но не неподъемно как кажется на первый взгляд, попробуйте.
Например, опечатки в assert-ах:
Еще находились кусочки кода, в тестах для которых вообще не покрыты граничные условия, при этом code coverage близился к 100%.
Была даже пара тестов которые при любом изменении тестируемого кода проходили ¯\_(ツ)_/¯
В целом, такие ошибки на большом и старом проекте будут всегда возникать, мутационные тесты помогут их выявлять и держать под контролем.
Но главное — мутационное тестирование поможем вам начать писать более качественные тесты прям со старта.
Проблема в том, как Infection модифицирует файл. Он делает перехват инклюдов через stream_wrapper_register(), и подменяет на лету заинклюженный файл на файл с мутировавшим кодом. По-сути SoftMock действуют так же, просто через другой механизм.
В результате, подружить их друг с другом довольно сложно. Это возможно, но пришлось бы очень сильно влезть в код Infection.
Если кратко, AspectMock умеет не все что нам было нужно.
Чтобы не пересказывать детали в комментарии — приведу статья, где мы подробно рассказывали зачем нам вообще понадобились софт моки habr.com/ru/company/badoo/blog/279617
Спасибо.