История о том, как мы ускорили тесты в 12 раз

[AigizK]

Чтоб ускорить скорость прохождения тестов в десятки раз, достаточно в самом начале разработки поставить Sleep(N minutes), а потом убрать.
А если серьезно, мокая что то, скорее всего надо будет написать интеграционный тест.
В предыдущем проекте было более 5000 сценариев, скорость выполнения 100-500 сценариев/сек в зависимости от машины. Но там отдельно тестировали сценариями бекенд, а для фронтэнда использовали силениум.
В новом проекте с помощью этого github.com/GoogleChrome/puppeteer пытаемся объединить сценарии БЭ+ФЭ

[Tumenbayev]

Мы сейчас на основе этого же мок-сервера изолировано пытаемся прогонять frontend средствами selenium. А в сторону puppeteer не смотрел, спасибо.

[Aquahawk]

Постепенно двигаюсь к пониманию того что наборы тестов должны быть поделены на несколько suite. Долгие, быстрые, минимальный регресс, подзадачные. Долгие собираются и гоняются раз в сутки или перед выкаткой например, могу длиться и час. Быстрые и минимал регресс гонять после каждого коммита, а подзадачные это мини сьют у каждого разработчика свой, где он включает только нужные тесты и при разработке гоняет только их, и только перед коммитом прогоняет локально быстрые и минимальный регресс. Пока у себя не внедрил, сейчас у нас есть по сути подзадачный, быстрый и медленный наборы.

[Tumenbayev]

Мы используем codeception и у каждого разработчика есть свой конфиг файл с настройками его окружения, а также есть возможность запускать тесты по файлово и группам.
И еще сейчас, у нас есть 4 suite (Acceptance, Component, Unit, Newman, Smoke).
Немного о newman: habr.com/company/kolesa/blog/353902

[ggo]

Еще одни моки github.com/php-vcr/php-vcr

[jetcar]

также нередко приходилось их перезапускать, чтобы добиться зеленой сборки,

вот в этом месте надо было фиксить проблему, а не мокая апи, если чтото замокано то функциональным тестом это больше назвать низя, и нужно писать ещё тесты которые без мока будут работать, а вашу проблему можно решить через докеры или деплой переделать так чтоб сервис был 99.9% времени в рабочем состоянии, с продакшеном же та же проблема когда релиз происходит

[Tumenbayev]

Тут дело такое…
Где-то могут вестись какие-либо работы, может что-то произойти с базой.
Но, замечания верные. Спасибо.

[jetcar]

с базой это наверно самое сложное, как делать миграции и ничего не ломать, но как уже писал это нужно и для продакшена, хорошо если можно на выходных или в нерабочие часы задеплоить и не сломать ничего, но с ростом проекта это окно всё меньше и меньше и чем раньше начать деплой правильно делать тем лучше, говорят есть приложения которые годами работают без перебоев :)

[Tumenbayev]

У нас большое количество разработчиков, у каждого из них подняты локально тестовые окружения и все они собирают сборки в bamboo, что не может не сказаться на нагрузке на тестовый АПИ и другие сервисы, поэтому это всё дорого.

[Fantyk]

Тоже считаю что проблему изначальную не решили, а обошли.
В первую очередь нужно добиться стабильности тестов.

С другой стороны вы пошли в направлении стандартных рекомендаций пирамиды тестирования: написали больше тестов покрывающих функционал какого-то модуля, при этом замокав взаимодействие с другими модулями.
Но не стоит полностью отказываться от кросс-модульных тестов, их может быть мало — но самые критичные сценарии лучше покрыть. Тем более у вас это уже реализовано.

[Tumenbayev]

Операции которые взаимодействуют и критичны для бизнеса покрыты всевозможными тестами

[jehy]

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

[Tumenbayev]

Звучит очень интересно. Но, мы так далеко еще не заходили. Еще :)

[redskif]

Имя, сестра, имя!

По каким словам гуглить, или может быть посоветуете статью где описывается что-то подобное?

[jehy]

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