Инструмент тестирования на основе браузера, который не нарушен?

Извините за спорный титул здесь!

Я провел честное тестирование на основе браузера (JS-тяжелых веб-страниц), используя библиотеки Selenium и Selenium, такие как Capybara. Всегда было большой болью на шее, чтобы тестовые наборы работали последовательно. Да, я знаю, что вместо того, чтобы вставлять вызовы на sleep() здесь и там, вы должны ждать, пока элементы DOM станут видимыми или будут соответствовать другим условиям yadda yadda. Это все хорошо, и это немного помогает. Я бы подумал, что я не делаю это совершенно правильно, если бы это было не так...

Если бы это было не по времени, прежде чем я когда-либо писал код Селена, когда компания, с которой я консультировалась, наняла фирму, которая специализируется исключительно на написании наборов тестов Selenium. Они отправили парня, который предположительно был экспертом в Selenium, и он написал полный набор тестов для нашего веб-приложения. Нужно ли вам рассказать, что произошло, когда мы действительно использовали тестовый пакет?

Я пришел к выводу, что весь подход, который использует такие инструменты, как использование селена, зависит от большого состояния гонки. У вас есть тестовый процесс и отдельный процесс браузера, которые говорят через сокет. Процесс тестирования отправляет запросы в браузер, чтобы узнать состояние DOM, и , когда браузер продолжает работать, вычисляет, что делать. Затем он отправляет отдельное сообщение в браузер для имитации щелчка или нажатия клавиши и т.д.

Если вы когда-либо писали многопоточные программы, вы знаете, что это просто не работает. Это гонка "чек-то-акт". Если тестовый процесс может заморозить выполнение JS в браузере, запросить его состояние, выпустить имитированные клики/нажатия клавиш, а затем разморозить браузер, тогда все будет в порядке. (Как использование блокировки для защиты критического раздела многопоточной программы.)

Единственный способ, которым я могу думать о том, чтобы обойти состояние гонки, - это для каждого тестового примера, который должен быть написан в JS. Это, конечно, исключает тестовые примеры, которые охватывают навигацию по нескольким страницам. Вам также нужен способ сброса страницы в "чистое" состояние в начале каждого тестового примера.

Кто-нибудь знает инструмент/подход для тестирования JS-приложений в браузере, которые позволяют смертным, таким как я, создавать тестовые сеты, которые работают на 100% последовательно, без вырывать все мои волосы?

(PS. Еще один вывод из опыта работы с Selenium: у многих бесплатных плагинов jQuery есть ошибки, которые не появляются, когда люди используют эту страницу, просто потому, что они не могут нажимать так быстро, как Selenium!)

ОТВЕТЫ

Ответ 1

Вы видели casperjs, который может работать поверх фантомов (браузера безглавых веб-китов) или slimerjs (безголовый браузер gecko)?

Синтаксис unit testing является чистым и дружественным, и он последовательно выполняет ваши тесты в контексте браузера, используя метод под названием evaluation().

Ответ 2

С момента, когда вы ответили на этот вопрос, появилась новая служба, Ghost Inspector. Тестирование пользовательского интерфейса на основе браузера без необходимости кодирования. У вас есть возможность делать ручные шаги в редакторе приложений, или вы можете использовать расширение Ghost Inspector Chrome, чтобы просто записывать свои взаимодействия с веб-приложением, которое вы тестируете.

Ghost Inspector также записывает каждый тестовый прогон, чтобы вы могли точно видеть, что видел браузер агента тестирования. В каждом тестовом прогоне есть подробные журналы, в том числе список каждого URL-адреса, который он нажал/посетил на этом пути. Вы можете запускать тесты Ghost Inspector с URL-адресом триггера, чтобы вы могли интегрировать его в процесс непрерывного развертывания.

Ответ 3

Я попытаюсь разобраться в вашей озабоченности по поводу того, что инструмент для автоматизации и сам браузер - это два отдельных процесса, поэтому автоматизация script является предметом условий гонки, о которых вы упомянули.

Именно поэтому я склонен писать сценарии автоматизации веб-приложений в процессе, поэтому они работают в одном цикле событий основного пользовательского интерфейса как сам браузер.

Там отличный инструмент для этого: Microsoft WebBrowser Control. Для создания автоматизации script вам нужно иметь некоторые навыки С#. С другой стороны, с такими языковыми функциями, как async/await, программирование WebBrowser - это легкий ветер, поскольку он, естественно, асинхронный (без этих противных Thread.Sleep и опросных циклов). Кроме того, вы можете выполнять все обычные задачи автоматизации, например:

Ответ 4

Он назывался "Selenium". И он работал, но не достаточно хорошо, в основном потому, что он был полностью построен на JavaScript. Проект Selenium продвинулся, приняв еще одну систему под названием "WebDriver" (также известный как Selenium 2.0), с более тесной интеграцией в браузеры, и теперь авторы браузеров строят драйверы в браузерах или в виде тесно связанных надстроек (например, OperaDriver, ChromeDriver).