У вас функция “покупка товара” - как можно покрыть ее по странице?
Если мы покрываем “по фичам” - никак. А если “по страницам” - легко. берем первую страницу, какой нибудь product details, покрываем тестами. Один из тестов будет “добавление в корзину”.
Дальше берем стр card. Покрываем ее тестами. В одном из тестов, предусловием будет “наличие товара в корзине” и тд.
это очень плохое решение
- а что будет если товара там не будет? страница рабочая а тест сломается.
- а что делать с краткосрочными операциями (ну, например возвращение какого нить кода ввода, на другой странице) пришли через 100 тестов - а кода уже нет.
- как валидировать вью страницы (страница изменения имени пользователя и страница профиля пользователя где это можно проверить)
Вы проверяете не страницы, а ФУНКЦИИ которые должны работать на приложении.
В случае который я описал тоже проверяются функции. Только изолированно друг от друга. Функция добавления товара в корзину, функция добавления товара в вишлист, правильное отображение товара в корзине.
Слышал мнение, что независсимые проверки лучше. Если упадет тест добавления товара в корзину, следующий тест который проверяет товар в корзине выполнится, потому что предусловия будут замокны.
Короч. Это холиварная тема. Если бы я был уверен на 100% в любом из подходов, я бы тут вопросы не задавал
Изолированно друг от друга тестируют unit покрытия.
Опять таки пример изменение имени пользователя с вью где то на другом конце приложения. То что вы смогли вбить текст в инпут, и нажать кнопку, не значит что данные ушли на сервер, и сохранились в бд, и будут показаны на вью.
Второй момент как Вы себе представляете data driven test с Вашим подходом? Будете хранить тонны сырых данных между тестами?
То есть, это попытка развести холивар. Я к Вам вроде с аргументами пришел.
фреймфорк по страницам
тесты по фичам
Не расскажите поподробнее?
у тебя, допустим, интернет магазин.
на странице1 расположен каталог
на странице2 расположена форма оформления заказа
на старнице3 расположена информация о заказе со всеми деталями (включая детали со страницы2, типа review order page) и собственно кнопка оплаты
на странице4 расположена инфа об удачном заказе.
чтобы сделать заказ, у тебя тест будет выглядеть так:
открыть страницу1 и найти товар. добавить в корзину. нажать кнопку оформить
проверить что станица2 загрузилась, добавить детали к заказу, выбрать способ оплаты и так далее. нажать кнопку оплаты
проверить, что страница3 загрузилась, сделать сверку с данными на странице и данными при оформлении заказа. нажать оплатить
проверить, что страница4 загрузилась и так-же сделать сверку с данными
а то я как-то видел кашу, как тест работает не понятно, название этих страниц не отражает сути того, что там находится и так далее
Ну так это вы говорите про то, как организовать библиотеку для хождения по страницам через Page Object Pattern или какой-либо другой структурный шаблон. К фреймворку это не имеет отношения.