У меня возникла следующая проблема на проекте.
У нас на проекте около 7 разных ролей с разными правами, в добавок у каждой из ролей могут меняться права в зависимости от добавленной ему роли, в общем получается около 40 разных кейсов, которые нужно проверить автотестами.
Мануальный тестер хочет, чтобы все тесты писались только на уровне UI (а это и долго, и тесты уже длятся больше 20 часов и т.д.), потому что так всегда было до меня на этом проекте.
А согласно пирамиде тестирования здравому смыслу, часть новых тестов я хочу писать (а существующие переписать) на уровне API.
Но есть одна загвоздка, я в этом новичок, поэтому мне нужно понимать, что можно писать на уровне апи, а что обязательно нужно проверять на UI (то есть как разделить между ними проверки грамотно), к тому же мне потом это нужно будет объяснить тестеру и команде.
Возьмем конкретный пример: мне нужно написать тесты, покрывающие проверку прав разных ролей написания, редактирования, удаления коммента и права видеть чужие комменты. При этом это нужно проверить в 40 разных случаях( так как права юзера могут поменяться, если у него появляется добавочная роль), на 3 разных страницах.
Проверка прав происходит на бэкэнде, но конечно же нужно проверить и на фронте, что кнопки видимы, кликабельны и т.д.
Правильно ли я рассжудаю. Пишу один E2E тест на UI: я могу зайти под админом (так как у него всемогущая роль и можно будет разом всё проверить), сделать всевозможные манипуляции с комментами.
Затем все остальные поверки для других ролей и их комбинаций сделать через API.
Пожалуйста, помогите разобраться, а то уже голова кругом идет, а посоветоваться не с кем))
Так
- Идея, что все протестить на уроне API будет удобнее и быстрее - правильная
- Понимание того, что UI все равно тестить придется - тоже норм
Я не видел системы, но предположу:
Просто сообщать на UI, в какой роли залогинен пользователь - нелогично. 7 ролей, надо писать кучу логики, что если такая роль, показывай это, если другая - то.
Существует подход, когда анонимный юзер логинится на сайте (запрос уходит к API) и получает, в ответ, помимо user-info еще перечень прав: что можно делать. Так удобнее разрабатывать UI и всегда можно добавлять/удалять/менять роли, не переживая за UI
Если я прав, то нужно изолировать компоненты и тестить:
- Тесты на API, где мы проверяем, что в ответе правильный перечень прав для роли
- Тесты на API, где пытаемся совершить действия, которые нельзя. Например, гость пытается поменять информацию о товаре (не знаю, о чем ваша система). Тут даже не важно, есть ли такой товар и валидны ли значения - вам должен вернуться статус 403. Значит проверка прав происходит до выполнения операций (да и вообще, проверка есть)
- Тесты на API, где пытаемся совершить действия, которые можно.
- Дальше, идеальная ситуация состоит в том, что вы берете ваш UI фреймворк (что там у вас? Angular, React, Vue?) и смотрите, какими инструментами они тестируются (у ангуляра есть свой модуль для тестирования, у реакта - Jest и т.д.)
- Мокаете сервер, мол, если юзер логинится так, верни перечень прав админа, если вот так - перечень прав юзера
- И пишете тесты, проверяющие, что вам правильно отображаются нужные UI-компоненты
- Ну и сколько-нибудь selenium-тестов сверху присыпьте, чтобы убедиться, что все это работает вместе хорошо. К тому же, позитивные сценарии (где пользователи джелают то, что им можно у вас реализованы в других тестах)
2 лайка