Отвечу, по пунктам. (мне кажется, вы не все прочитали или не дочитали).
Эндпоинты естественно могут быть связаны. Вы же сами можете формировать связный сценарий. Мой комментарий о несвязности относится к тому, что мы не можем создавать сущности в процессе теста и обращаться к ним (никто не мешает прописать это для вашей системы). Если мы обращается к существующем на стенде сущностям, то эндпоинты вполне себе связанные
Авторизация. Естественно авторизация должна быть, я вынес в репозиторий примеры bearer токен авторизации и авторизации статичным токеном (довольно во многих системах присутствует генерации безопасного не протухаюшего токена. Почему ей нельзя пользоваться?)
Менеджеры. Менеджер и не должен повторять полностью все эти шаги. Я написал в тексте, что работа менеджера/аналитика/ручного тестировщика заключается в том, что они должны выгрузить har после прохождения сценария в интерфейсе. Не думаю, что это сложная задача. Все остальное (генерация НТ, запуск теста и тд должно происходить автоматически по кнопке в CI/CD или как то ещё. Инструкция по созданию теста написана для демонстрации как это работает (по сути никто этого не делает руками, у меня это делает Jenkins)
Возможны вы правы, мое имхо несколько отличается) (не все тестировщики все-таки готовы к работе с кодом)
Плюс еще в том, что разработчики/аналитики/менеджеры тоже по отчету могут понять, что конкретно не работает (или работает) и попробовать разобраться, пока тестировщик занят
Я использовал cursor. Это IDE, форк vs code с интегрированными моделями внутри
Приветствую
Отвечу, по пунктам. (мне кажется, вы не все прочитали или не дочитали).
Эндпоинты естественно могут быть связаны. Вы же сами можете формировать связный сценарий. Мой комментарий о несвязности относится к тому, что мы не можем создавать сущности в процессе теста и обращаться к ним (никто не мешает прописать это для вашей системы). Если мы обращается к существующем на стенде сущностям, то эндпоинты вполне себе связанные
Авторизация. Естественно авторизация должна быть, я вынес в репозиторий примеры bearer токен авторизации и авторизации статичным токеном (довольно во многих системах присутствует генерации безопасного не протухаюшего токена. Почему ей нельзя пользоваться?)
Менеджеры. Менеджер и не должен повторять полностью все эти шаги. Я написал в тексте, что работа менеджера/аналитика/ручного тестировщика заключается в том, что они должны выгрузить har после прохождения сценария в интерфейсе. Не думаю, что это сложная задача. Все остальное (генерация НТ, запуск теста и тд должно происходить автоматически по кнопке в CI/CD или как то ещё. Инструкция по созданию теста написана для демонстрации как это работает (по сути никто этого не делает руками, у меня это делает Jenkins)
Приветствую, уже все интегрировано за вас)
Смысл в том, что шаги, которые написаны на человеческом языке имплементируются (переводятся) в код фреймворком behave, при запуске тестов
В репозитории в директории features/step есть реализация каждого шага, а в директории features/test сами тесты
П
Возможны вы правы, мое имхо несколько отличается) (не все тестировщики все-таки готовы к работе с кодом)
Плюс еще в том, что разработчики/аналитики/менеджеры тоже по отчету могут понять, что конкретно не работает (или работает) и попробовать разобраться, пока тестировщик занят