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