Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Организация тестов. По сценариям или по страницам?

design-patterns
management
architecture
framework
page-object
Теги: #<Tag:0x00007fedc40e1af0> #<Tag:0x00007fedc40e1988> #<Tag:0x00007fedc40e17d0> #<Tag:0x00007fedc40e1618> #<Tag:0x00007fedc40e13e8>

(Goshko Nazar) #21

У вас функция “покупка товара” - как можно покрыть ее по странице?:worried:


(Ivan Pletin) #22

Если мы покрываем “по фичам” - никак. А если “по страницам” - легко. берем первую страницу, какой нибудь product details, покрываем тестами. Один из тестов будет “добавление в корзину”.
Дальше берем стр card. Покрываем ее тестами. В одном из тестов, предусловием будет “наличие товара в корзине” и тд.


(Goshko Nazar) #23

это очень плохое решение

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

Вы проверяете не страницы, а ФУНКЦИИ которые должны работать на приложении.


(Ivan Pletin) #24

В случае который я описал тоже проверяются функции. Только изолированно друг от друга. Функция добавления товара в корзину, функция добавления товара в вишлист, правильное отображение товара в корзине.

Слышал мнение, что независсимые проверки лучше. Если упадет тест добавления товара в корзину, следующий тест который проверяет товар в корзине выполнится, потому что предусловия будут замокны.

Короч. Это холиварная тема. Если бы я был уверен на 100% в любом из подходов, я бы тут вопросы не задавал :slightly_smiling_face:


(Goshko Nazar) #25

Изолированно друг от друга тестируют unit покрытия.
Опять таки пример изменение имени пользователя с вью где то на другом конце приложения. То что вы смогли вбить текст в инпут, и нажать кнопку, не значит что данные ушли на сервер, и сохранились в бд, и будут показаны на вью.
Второй момент как Вы себе представляете data driven test с Вашим подходом? Будете хранить тонны сырых данных между тестами?

То есть, это попытка развести холивар. Я к Вам вроде с аргументами пришел.


(Anton Tereshko) #26

фреймфорк по страницам
тесты по фичам


(Sergei Chipiga) #27

Не расскажите поподробнее?


(Anton Tereshko) #28

у тебя, допустим, интернет магазин.
на странице1 расположен каталог
на странице2 расположена форма оформления заказа
на старнице3 расположена информация о заказе со всеми деталями (включая детали со страницы2, типа review order page) и собственно кнопка оплаты
на странице4 расположена инфа об удачном заказе.

чтобы сделать заказ, у тебя тест будет выглядеть так:

открыть страницу1 и найти товар. добавить в корзину. нажать кнопку оформить
проверить что станица2 загрузилась, добавить детали к заказу, выбрать способ оплаты и так далее. нажать кнопку оплаты
проверить, что страница3 загрузилась, сделать сверку с данными на странице и данными при оформлении заказа. нажать оплатить
проверить, что страница4 загрузилась и так-же сделать сверку с данными

а то я как-то видел кашу, как тест работает не понятно, название этих страниц не отражает сути того, что там находится и так далее


(Sergei Chipiga) #29

Ну так это вы говорите про то, как организовать библиотеку для хождения по страницам через Page Object Pattern или какой-либо другой структурный шаблон. К фреймворку это не имеет отношения.