Комментарии 2
При чтении статьи, местами возникает ощущение, что вы сами создали себе проблемы, которые потом героически решали (и теперь есть о чем поделиться на Хабре).
Нет, схема то интересная. Но если она у вас решила одну проблему, но добавила две - то возможно такая схема не совсем подходит?
Если вы можете выполнять последовательно первые шаги всех сценариев, а потом делать ожидание и выполнять проверки (на момент проверок созданы куча заказов и прочих данных для всех сценариев разом, т.е. друг другу они не мешают), то почему же вы не могли просто распараллелить все сценарии?
С самого начала посыл стоял в том, что вас не устраивали задержки по 10сек в каждом тесте. При этом пассивное ожидание я уже давно нигде не встречал. Есть же такие библиотеки как awaitility, позволяющие делать "активное" ожидание (проверка производится с заданной периодичностью в течение некоторого времени, после которого наступает timeout). И вместо того, чтобы всегда ждать 10 сек, вы будете проходить проверку как только, так сразу.
Автоматические проверки - хорошо. Но неявные проверки, которые для теста обязательны - не очень хорошо. Есть риск, что такую проверку из общего места уберут (допустим она будет неприменима для большого количества новых тестов), а туда, где она была нужна - не добавят. Потому что забудут, и потому что будет неочевидно, кому она была нужна. То есть на данный момент, добавляя новый тест, вам нужно держать в голове, где какие проверки делаются неявно.
Сделайте скидку на то, что в этой статье примеры очень игрушечные. В реальной жизни тестировались отнюдь не интернет-магазины, а достаточно сложные финтех системы с очень "богатым" расписанием. В них огромное количество вещей происходит не потому-что вы дёрнули какой-то API, а потому-что пришло для этого время. Смотрите пример с агрегацией доставок в 18:00 из начала статьи.
Именно из-за расписания запускать сценарии просто параллельно при этом невозможно, их нужно синхронизировать между собой по массовым операциям.
Просто для понимания масштаба проблемы: одна из тестовых библиотек покрывала две недели плюс последний день месяца работы реальной системы. При этом полный регрешен составлял более 6000 сценариев и около 3600 Global Steps.
Проблемы которые мы решали и решили описаны в конце статьи: проверки больше не теряются, ошибки сценариев видны в отчётах и т.д. История про 10сек – это просто пример... Но мы часто сталкиваемся с тем, что единственный способ корректно выполнить проверку, это ввести фиксированную паузу. Если есть возможность сделать "умное" ожидание, то мы всегда предпочитаем его.
Автоматические проверки - хорошо. Но неявные проверки, которые для теста обязательны - не очень хорошо.
Автоматические проверки несколько раз помогли нам найти проблему после ручного тестирования. Просто потому, что тестировщик не подумал сделать проверку в промежуточном этапе. Ну и по мере роста тестовой библиотеки, ручная расстановка проверок – это определённая боль: кто-то её просто пропустит, какая-то проверка добавиться когда у вас уже есть несколько сотен сценариев и добавлять её руками будет проблематично.
P.S. Эта схема и правда подходит только для весьма специфичных случаев, но если подходит… то работает более чем отлично )
Автоматизация e2e тестирования систем с расписанием