Теперь у меня какое-то дежавю: я снова не вижу ни одного 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 и разделы про тестирование на программистских конференциях.
Одну ногу я побрила…