testomat.io управление авто тестамиКак обстоят дела с распараллеливанием тестов у бдд фреймворков, кто пользовался/знает ? Посмотрел пару видео, все рассказывают как это круто использовать бдд и вот с селениумом, и с чем хочешь, а тема как-то не освещена. Я вот перепробовал behave, lettuce и плагин для nose freshen, и похоже в официальном виде не умеет никакой из них. Питон 3.3, да и в 2.+ надежда только на nose…
Python BDD фреймворки, такого не умеют. Но это какая-то общая тенденция для BDD фреймворков, мало кто включает такую функциональность. Хотя я тоже не понимаю, почему нельзя сразу такое сделать, так как параллелизация тестов это фундаментальный кирпич хорошей автоматизации. Тут я бы сказал, придется самому доделывать.
Да, собсвенно выхода два, либо делать параллелизацию самому, либо делить на сьюты и пускать в разных джобах дженкинса.
Я кстати для одного проекта сейчас именно делаю второй вариант. ИМХО нормально если небольшое количество тестов. Если много, то надо параллелизацию делать программным способом.
Вот кстати думал над этой проблемой. Хотел реализовать паралельный запуск тестов в своем BDD фреймворке Codeception. Вопрос достаточно непростой и может усложнить работу с системой в разы, добавить новых системных требований, а в итоге работать не для всех и не так как надо. А ещё, естественно, могут быть проблемы с совемстимостью между различными ОС.
Варианты я нашел такие:
- Действительно логично, чтобы паралелизацию делал CI сервер - мы запускаем не пересекающиеся группы тестов, ждем результатов, обьединяем их. Впрочем, на предпоследнем пункте как раз и возникает проблемма - как мы можем мониторить окончание работы процесса? Писать свой плагин для дженкинса? М… Нет. Не хочется.
- Второй вариант - есть мастер процесс, который работает как сервер, он запускает дочерные процессы со своими конфигурациями, с группами непересекающихся тестов, получает от них результаты, и когда все результаты пришли - обьединяет их и строит отчет. Круто, за исклюением того, что надо по сути писать новое приложение - менеджер процессов и делать распределенную систему в стиле master-slave. Ещё нужно сериализировать - десериаизировать данные при передаче и писать протокол под это дело. Плюсы - паралельные тесты можно гонять на разных нодах.
- Ну и третий вариант - нативная паралелизация через процессы. Делается несложно, за исключением того что скорее всего придется перелопатить весь код фреймворка (если он не готов к такому, то можно что-то хорошенько сломать). Итоговое решение будет элегантным, но возможно бессмысленным, из-за отусттвия возможности запускать тесты на разных машинах. Кроме того процессы (Threads) не реализаны толком в Руби, по дефолту не стоят в РНР, ну и впринципе с ними одна головная боль, насколько я знаю.
- Ещё вариант - гибрид второго и третего, но с использованием job-сервера, или сервера очередей. AMQP, Gearman, etc. На самом деле всё круто за исключением того, что придется потрахаться с установкой стороних сервисов, и не дай бог они отвалятся где-то - вам придется разбирать почему и как. Ну и конечно же, при поломке джоб сервера проклятия посыпятся на голову разработчиков тестового фреймворка. Не, хочется спать спокойно ) И не поддерживать сторонние решения.
Итого… Фича вроде и полезная, но обьективно говоря, нужна очень немногим людям. И по сути она требует слишком многого для реализации и установки. То есть, я лично считаю, что это уже премиум фича и её нужно продавать. Лично я бы делал вариант 2 или 4. Ещё не решил как лучше. Но вцелом задание не на денек и чтобы угодить всем - придется постараться.
Если есть ещё идеи про то как делать паралелизацию - будет интересно услышать.
1 лайк
Я частенько замечаю, что делают именно 2й вариант, к которому ты склоняешься. Тем более, что этот подход дает возможность легко сделать удаленный запуск на других машинах.
А в общем, я согласен, что это нетривиальная задача, но это не означает, что ее не нужно делать. Например, чисто для меня, встроенная возможность параллельного запуска является очень важным критерием при выборе фремворка или инструмента автоматизации. Я вот как раз сейчас делаю проект, и намерено ушел от хорошего высокоуровневого фреймворка где плохо с параллелизацией, в сторону низкоуровневого xunit фреймвока с встроенной параллелизацией на основании, которого буду делать нужное мне решение.
Другими словами, если ты это реализуешь у себя в проекте, то это будет заметно выделять твой фреймворк от других. Говорю чисто субъективно, но думаю, многие со мной соглашаться.
На счет того что это не всем надо, поверь, рано или поздно необходимо сокращать время выполнения тестов. А такие случаи наступают часто. Или у тебя есть какая-то своя статистика?
1 лайк
В итоге, в Codeception 2.0 добавил возможность запуска параллельных тестов по второму варианту. Наверное, я не совсем осознавал, когда писал свой предыдущий пост, что самой большой проблемой будет не запуск и обьединение результатов, а всё-таки создание изолированой среды для процессов. Тесты не должны влиять друг на друга, а значит, если это веб-тесты, они должны работать с разными хостами и разными базами данных.
И тут варианта два: пойи нахрапом и насоздавать 10 хостов и 10 баз данных на каждый процесс, или виртуализировать всё через докер и выполнять каждый процесс внутри контейнера. Второй вариант круче, первый - проще.