Классический е2е это обычно черный ящик, надо подтвердить что полоьзовательский сценарий работает. Наши "интеграционные" это скорее workflow/system tests на реальном стенде, где мы проверяем не только Ui путь, но и работу связки подсистем в условиях максимально близких к под-конфигурациях. То есть е2е это прог "пользовательский путь" , а "интеграционные" про "реальная система + интеграция модулей" иногда с более техническими проверками. Касаемо предусловия через Ui, в статье было описано почему был выбран такой путь ;)
Спасибо за комментарий! Я понимаю, что редизайны могут вызывать сложности, особенно в контексте автоматизации тестирования. Мы стараемся использовать паттерн Page Object Model, чтобы минимизировать влияние изменений на тесты.
Что касается явных декораций, наш код уже содержит аннотации, такие как @Test, @Issue, @Story и @DisplayName. На данном этапе их нам вполне достаточно. Также стоит отметить, что названия методов описывают их функциональность, что тоже можно считать своего рода декорацией.
Спасибо за комментарий, такая логика тоже имеет место быть. Однако нам визуально проще держать их в одном классе, так же такая практика описана в книгах Selenium Design Patterns and Best Practices и Automated Testing with Selenium
Классический е2е это обычно черный ящик, надо подтвердить что полоьзовательский сценарий работает. Наши "интеграционные" это скорее workflow/system tests на реальном стенде, где мы проверяем не только Ui путь, но и работу связки подсистем в условиях максимально близких к под-конфигурациях. То есть е2е это прог "пользовательский путь" , а "интеграционные" про "реальная система + интеграция модулей" иногда с более техническими проверками.
Касаемо предусловия через Ui, в статье было описано почему был выбран такой путь ;)
Спасибо за комментарий! Я понимаю, что редизайны могут вызывать сложности, особенно в контексте автоматизации тестирования. Мы стараемся использовать паттерн Page Object Model, чтобы минимизировать влияние изменений на тесты.
Что касается явных декораций, наш код уже содержит аннотации, такие как @Test, @Issue, @Story и @DisplayName. На данном этапе их нам вполне достаточно. Также стоит отметить, что названия методов описывают их функциональность, что тоже можно считать своего рода декорацией.
Спасибо за комментарий, такая логика тоже имеет место быть. Однако нам визуально проще держать их в одном классе, так же такая практика описана в книгах Selenium Design Patterns and Best Practices и Automated Testing with Selenium