Но я кажется понял общее негодование, ожидался ответ на вопрос 'как?' а не 'зачем?'. Учту) Ну и формулировки подкорректирую, космолёт я тут и правда никакой не строил, хотя и не думал что это ожидают)
Замечания резонные но в целом решаемые при желании, даже с такой реализацией но со всякими дополнениями/изменениями. Все индивидуально для каждого проекта) 1) можно попросить настроить отдельно/делать повторную авторизацию посреди тестов(костыль). 2) тут не понял, так и все тесты могут упасть без этого. 3) Тут да, зависит от сценариев, но в целом наверно можно подчищать.
Для первой итерации можно зайти с другой стороны - смотреть на статус коды.
Кажется я где-то это видел, когда-то. И понял почему не стал думать в этом направлении, ну опять же это лично моё мнение: это просто доп. категория разделение кейсов, она будто бы излишне. Ведь эти кейсы и так внутри содержат позитив/негатив.
Мы же можем отслеживать, по каким путям ходим (через тот же requests) и какой результат получаем?
Можем конечно. Просто это не всегда тривиально из-за особенностей реализации от сваггера к сваггеру. Тут уже вопрос к парсеру который будет это делать.
Писать руками тс по покрытию api тестов это как будто не про автоматизацию.
Согласен)
И 200 будут для нас приоритетным и главными(happy path). И так же проверять условные остальные 401/403 и 400. Или можно составить список, какие статус коды мы ожидаем от эндпоинта и их проверять (это и будет покрытие).
Сначала не понял, потом как понял! Но я пока не знаю что на это сказать, это интересная мысль.
как понять что был сделан вызов в конкретный эндпоинт - просто спарсить одной функцией не получится... попадается очень длинные и напичканые всем подряд эндпоинты, котоыре нужно сначала индифицировать.
как понять что сделанный вызов делал конкретную проверку
как понять какой у нас исчерпывающий список необходимого покрытия
Вообще не знаю, мне пока стыдно показывать да и не хотелось бы чтоб восприняли как рекламу. Я наверно отдельную статью сделаю как закончу: есть у меня фреймворк partest - можно в pypi найти. Он занимается отслеживанием покрытия на основе сваггера, в настройки можно указать название тест-кейсов которые участвуют в "100% покрытии" и исключения.
Согласен, правда если говорить про интеграции тут всё относительно и сильно зависит от стенда, наличие тестовых сред у интеграционных сервисов и т.п. В целом, имхо, кажется и это можно привести к какому-то единому подходу.
Ошибку осознал, Благодарю.
Буду делать) я это воспринимаю как хороший опыт
Но я кажется понял общее негодование, ожидался ответ на вопрос 'как?' а не 'зачем?'. Учту) Ну и формулировки подкорректирую, космолёт я тут и правда никакой не строил, хотя и не думал что это ожидают)
это пример, не?
Переименовал специально для Вас))
В общем смысле, да, я могу это назвать фреймворком. Вы правильно меня поняли. Он не обязан быть написан с нуля.
набор инструментов, компонентов и методов, которые облегчают разработку программного обеспечения. (гугл)
Замечания резонные но в целом решаемые при желании, даже с такой реализацией но со всякими дополнениями/изменениями. Все индивидуально для каждого проекта) 1) можно попросить настроить отдельно/делать повторную авторизацию посреди тестов(костыль). 2) тут не понял, так и все тесты могут упасть без этого. 3) Тут да, зависит от сценариев, но в целом наверно можно подчищать.
Привет! Я мало знаком с продуктом, но меня интересует: реализовано или планируется интеграция с автотестами?
Кажется я где-то это видел, когда-то. И понял почему не стал думать в этом направлении, ну опять же это лично моё мнение: это просто доп. категория разделение кейсов, она будто бы излишне. Ведь эти кейсы и так внутри содержат позитив/негатив.
Там под капотом как раз таки requests и нет возможности указать локальный адрес сваггера. Для моих проектов это не подходит.
Можем конечно. Просто это не всегда тривиально из-за особенностей реализации от сваггера к сваггеру. Тут уже вопрос к парсеру который будет это делать.
Согласен)
Сначала не понял, потом как понял! Но я пока не знаю что на это сказать, это интересная мысль.
Тут мы упираемся в следующее:
как понять что был сделан вызов в конкретный эндпоинт - просто спарсить одной функцией не получится... попадается очень длинные и напичканые всем подряд эндпоинты, котоыре нужно сначала индифицировать.
как понять что сделанный вызов делал конкретную проверку
как понять какой у нас исчерпывающий список необходимого покрытия
Вообще не знаю, мне пока стыдно показывать да и не хотелось бы чтоб восприняли как рекламу. Я наверно отдельную статью сделаю как закончу: есть у меня фреймворк partest - можно в pypi найти. Он занимается отслеживанием покрытия на основе сваггера, в настройки можно указать название тест-кейсов которые участвуют в "100% покрытии" и исключения.
Согласен, правда если говорить про интеграции тут всё относительно и сильно зависит от стенда, наличие тестовых сред у интеграционных сервисов и т.п. В целом, имхо, кажется и это можно привести к какому-то единому подходу.
На данный момент ответ будет - да, но я работаю над автономностью всего процесса).
да потому что сыра не будет вашего итальянского, ахахахах
Пасиб!