devepshko

 

 

 

можно на этом моменте поподробнее?

вот есть программный код который запускает Селениум, в том же коде надо описать методы которые создают тестовые данные (не надо никакого внешнего скрипта)

 

эти методы вызывать прямо из теста, перед запуском кода который поднимает Селениум

 

got it, но громоздко получается с одной стороны и не будет работать с другой (в моем случае). Фикстура создается и разрушается для каждого теста, поэтому получается, что этот код для данных будет выполняться перед каждый тестом...

пайтоновский скрипт тут видимо лишний, ведь сетап теста может эти же самые данные и создавать

можно на этом моменте поподробнее?

Итак, что в итоге есть на текущий момент (если кому то интересно). Небольшая ремарка, чтобы был понятен нижеописанный подход: тесты гоняются параллельно в 8-10 потоков для каждого браузера (сначала все тесты на хроме, потом - на фф, потом - в эдже, потом - ие), для этого используются разные учетные записи (1 тест - 1 поток - 1 учетная запись) - для стабильности.

Сейчас использую 2 подхода для подготовки тестовых (предопределенных) данных.

1) на пайтоне был написан скрипт, который парсит json файл и через API добавляет данные для тестов. Этот вариант используется для добавления данных на все аккаунты, т.к. не известно, какой аккаунт будет использован для конкретного теста. Скрипт запускается один раз при запуске задачи в Дженкинс перед непосредственно самими тестами.

2) некоторые тесты оперируют одними и теми же объектами (например, настройки профиля), поэтому перед отдельно взятым тестом все так же через API данные "сбрасываются". Первый подход для этих тестов не подойдет, т.к. на одну учетную запись могут попасть конкурирующие тесты. 2й подход, на первый взгляд, подойдет для тестов из 1го подхода. Но, как мне кажется, эффективнее добавить данные сразу, чтобы не выполнять аутентификацию в API для каждого теста.

Остается нерешенным вопрос с поиском - самый критичный в плане получения ожидаемого результата. Сложность заключается в том, что нужно добавлять свои данные в индексы ES, либо создавать отдельные только для тестов.

devepshko, что в итоге получилось? Подготовку тестовых данных сделали?

и да, и нет (= для текущей версии сервиса из-за замены его новой версией решили, что нет смысла ресурсы туда направлять. А для новой система будет такая (поиск, например):

1) подготавливаются тестовые данные (то, что ввожу в поля поиска)

2) описывается ожидаемый результат (результат на сайте - таблица) со значениями полей таблицы (в json скорее всего)

3) собирается тестовый билд

4) при запуске тестов в дженкинсе выполняется сначала удаление предыдущих подставленных данные, а затем - инжект новых чистых

Но это опять же в теории, как договорились с девелоперами.

 

Ожидание отрабатывает, т.е. драйвер видит, что элемент появился

 

until(

ec.presence_of_element_located(locator))

 

Одно из самых бесполезных и бессмысленных ожиданий, на мой взгляд. 

Нужный элемент может присутствовать в DOM даже, если Вы его не видите.

Также, как и наоборот - может быть не кликабельным, даже если Вы его видите и Вам кажется, что все ок.

Если нужно кликнуть - лучше ждать кликабельности (element_to_be_clickable).

 

с ожиданиями вообще не всегда все так гладко, как хотелось бы (= Иногда и кликабельности недостаточно, если какие-то скрипты еще DOM обновляют... вот элемент вроде бы появился и кликабельный, а потом DOM обновился и получаешь Exception.... но это уже наверное к вопросу о степени прямости рук девелоперов (=