Теперь у меня какое-то дежавю: я снова не вижу ни одного Java-программиста, изучившего Scala и отказавшегося от этого языка.
Я пробовал и отказался. И дело не в языке — он крутой, а в инфраструктуре. Если sbt заменят на что-то более удобное, полечат проблему с компиляцией под разные версии Scala и сделаю базовые артефакты поменьше размером, то может быть сделаю еще попытку.
Извините за долгий ответ. Мы используем Gridrouter с OS X аналогично остальным браузерам, только вместо стандартной Selenium ноды используем Appium и Xcode, который тащит за собой нужные симуляторы и SDK. К сожалению по лицензионным соображениям нельзя устанавливать MacOS не на виртуальные машины в облаке, только на железки, на каждую из которых можно поставить не больше 2 параллельно работающих операционных систем. Это сильно ограничивает масштабирование решения.
Selenium позволяет держать разные мажорные версии браузера на одной ноде, но с точки зрения администрирования делать так — одна большая проблема. Поэтому оказалось удобным ставить разные мажорные версии браузера на разные виртуальные машины: легче настраивать, легче переводить железо в браузеры и так далее. С точки зрения тестов ничего не меняется — указывается название браузера и версия, а gridrouter сам знает (это прописано в XML конфигурации) на какую машину пойти, чтобы отдать нужный браузер.
Поскольку мы работаем с большими объемами браузеров, то довольно важный вопрос — об эффективности использования железа. Типичный железный сервер имеет 24 и более ядра и больше 50 Гб памяти. Для того, чтобы не думать об аппаратном уровне мы используем облако. Для экономии ресурсов и обеспечения изоляции браузеров на одной виртуальной машине мы поднимаем несколько нод в разных виртуальных рабочих столах по 1 браузеру в каждой. Если этого не делать, то, например, начинаются проблемы с пропаданием фокуса на окнах браузера.
Нагрузка на хабы у нас более менее обычная: открытие страниц, выполнение действий в текстовых полях, снятие скриншотов и т.п. Тем не менее десятки нод на одном хабе приводят к ощутимым тормозам, даже на мощном железе.
Скорее статья не для начинающих, а для тех кто любит «поколбасить» своего кода. Товарищи начинающие! Не тратьте время! Берите готовые библиотеки и лучше пишите что-нибудь полезное!
Есть парочка форумов, которые слабо поддерживаются или по большей части просто содержат копипасты статей западных авторов. Есть парочка онлайн вебинаров, направленных больше уже на сформированные отдеы тестирования и на повышение квалификации тест-менеджеров.
Есть же разные специальные конференции для тестировщиков, типа SeleniumConf, SeleniumCamp и разделы про тестирование на программистских конференциях.
К моему счастью, бэк-енд команда согласилась параллельно с RESTful запустить JSON-pure API, просто перенеся все свои методы и коды в JSON. Спустя несколько месяцев все мои знакомые, ранее использовавшие RESTful, перешли на JSON-pure, осознав, что это гораздо удобнее.
Если все статьи будут в таком же газетном стиле, когда количество полезной информации уменьшается сверху вниз (как в этой статье), то должно прикольно получиться.
Мне не очень нравится, что используется свой формат описания маршрутов. Это скорее всего означает, что в любой IDE или редакторе оно будет выглядеть как обычный текст даже без подсветки синтаксиса, не говоря уже о проверке ошибок. Если сделать описание маршрутов на каком-нибудь языке программирования (например, Java или Groovy), то хотя бы при ошибке в конфигурации не будет компилироваться.
Можете ли вы пояснить на каких количествах одновременно запущенных виртуальных машин тестировалось данное решение? Есть ли информация о пределе, на котором ваше решение перестает работать корректно?
Есть же разные специальные конференции для тестировщиков, типа SeleniumConf, SeleniumCamp и разделы про тестирование на программистских конференциях.
Одну ногу я побрила…