Как избежать конфликтов, которые запускают тесты Selenium параллельно, когда они должны использовать базовый API REST?

Question

У меня есть веб-приложение, которое необходимо протестировать в нескольких браузерах в разных средах (например, Chrome, Firefox и Internet Explorer в Windows и Linux * (* с очевидным исключением Internet Explorer)).

Тесты были написаны на Java с использованием JBehave, Selenium и SerenityBDD (Thucydides)). Эти тесты используют базовый API REST, проверяя, могут ли объекты быть успешно созданы и удалены с использованием пользовательского интерфейса.

Я использую Selenium Grid и хотел бы запустить тесты на параллельных узлах; однако проблема состоит в том, что, поскольку тесты используют базовый API REST, могут быть конфликты.

Можно ли передавать параметры в тесты в качестве параметра в задаче конфигурации Jenkins, которая запускает тесты, так что есть небольшая разница в тестах, зависящих от узла, в котором они выполняются? (например, объект с именем «MYOBJECT-CHROME» создан в Chrome по сравнению с объектом с именем «MYOBJECT-FIREFOX» в Firefox, что означает, что можно избежать конфликтов API REST?)

Answer 1

Если тестируемое программное обеспечение (SUT) позволяет многопоточный запрос API REST, вам не нужно беспокоиться о

означает, что любые конфликты можно избежать?

Испытания параллельных запросов должны быть настроены как светильники, что означает, что каждый атомный тест должен устанавливать/сбрасывать требуемые для него тестовые данные или возвращать состояние программного обеспечения в тестовом режиме (SUT). Хорошим кандидатом здесь является Prebuilt fixture. Это позволит вам добавить его в качестве шага в Jenkins и может уменьшить накладные расходы на создание всех этих тестовых объектов.

Если вам все еще нужно parameterize the build, вы можете использовать свой набор @tags от BDD, чтобы определить, какой набор тестов будет выполнен.