для выразительности точно не надо - реально читаемость теста падает. Лучше как выше заметили - раздельные тесты

Они и так раздельные

Ща поясню подробнее

Короче есть у меня контекст, в нём стартует N драйверов. Короче сколько укажу, столько и будет.
Когда тесты запускаю в тимсити, там стартует докер, я использую ремоут драйвер и всё тоже параллелится как мне надо. Вопрос не в этом.

Есть у меня короче

class ClientPage {
  def deleteClient: Either[DeleteError, ConfirmDialog] = {
    ...
  }
}

Тип такой может быть не знаком, но Either обозначает, что метод может вернуть либо тип слева, либо тип справа. Одно из двух.
Ну и внутри этого метода запускатся параллельный поиск либо сообщения об ошибке, либо окна с подтверждением.

Ну и есть у меня тест#1, который проверяет что deleteClient вернул ошибку (тип слева), а тест#2 проверяет что deleteClient вернул ок (тип справа)

Ну я понял, ты предлагаешь поиск вынести в сам тест, но у меня в тестах вообще работы с драйвером нет.
Типа всё сокрыто в page-классах.

class ClientPage {
  def deleteClient: Either[DeleteError, ConfirmDialog] = {
    ...
  }
}

а параллельный поиск несет какой то сакральный смысл? тут можно и последовательные вызовы. ЧТо будет быстрее - надо смотреть, как там текущий вебдрайвер работает я не в курсе, впрочем в чате точно есть люди, которые должны знать

Неа, можно и последовательный. Типа поискал первый элемент, не нашёл. Поискал второй элемент.
Но искать оба одновременно меньше кода 😏

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

Ну да, если только опытным путём. Пока есть только один такой тест, он отработал 😄

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

я бы сам прогнал тестик, но я от селена достаточно давно очень далек :)

драйверы selenium по замыслу однопоточные и синхронные, нет никакой гарантии, что при параллельном выполнении запросов  вы получите осмысленный результат. может быть отказ, может быть падение драйвера. выполняйте запросы к драйверу последовательно. а если вам надо поискать "этот элемент или тот" — просто используйте составной локатор, а потом смотрите на найденный элемент, "этот" он или "тот"

Да, тоже идея, спасибо.

Что-то тут явно не то. Не в ту стороны пляшете. Запускать параллельные потоки… ДЛЯ ВЫРАЗИТЕЛЬНОСТИ? Серьёзно?

Нет, тут точно никакие параллельные потоки не нужны.
1. В том тесте, где должно появиться DeleteClientErrorDialog, ждите только его. Появился - ок, не появился - тест упал.
2. В том тесте, где должно появитьсяDeleteClientConfirmDialog, ждите только его. Появился - ок, не появился - тест упал.

У меня оно так и работает.

Если использовать всякие абстракции, типа фьючей, то это легко. Естественно я не делаю new Thread, это дичь)
А с фьючами параллельное исполнение двух разных действий оч легко описывать.

Да дело не в том, как это описывать. Это в принципе тут не нужно.

Кто-нибудь юзает Atlas от qameta у себя на проекте?

Доброе утро, коллеги.  В течение нескольких дней проявляется некая аномалия. Часть тестов, немного (5-7 за прогон), но все равно прилично по сравнению с ранними прогонами падает по причине того, что не дожидается стартовой страницы входа.

Стек: cucumber - capybara - ruby.Тестирую через chrome.
На падение стоит снимок экрана - он просто пустой (белый)

В логе теста просто (картинка). Посмотрел логи сервера - криминала не увидел. Установил время ожидание страницы 2 минуты (было 1 минута) лучше не стало.

Что можно еще придумать, чтобы идентифицировать проблему.