Ребят, столкнулся с тем, что наговнокодил(как обычно) и не разделил тест-кейсы с логикой тестов.
Пока пробовал кастомный YAML парсер, но штука тяжеловесная и хочется что-то побыстрее сейчас.

Вопрос 1: как у вас реализованы слои "логика тестов" - "тест-кейсы"/"данные"
Вопрос 2: от копипасты при составлении тест-кейсов для автоматизации никак не уйти, верно?

p.s. там, где можно красиво параметризовать, я это сделал, всё крутится. Однако тут OpenAPI.
Спасибо!

попробуй БДД

а вообще ЯННП

тест-кейсы - это тестовая документация

по ним пишутся автоматические тесты или проводят мануальные

Моя проблема - автоматизация может покрыть достаточно много, но либо это делается через параметризацию (и тогда появляется зависимость), либо это делается копипастой.

Я уже попробовал и то и другое и если честно, не очень вкусно.

Также замечу, что компания "быстрая, шустрая, продвинутая и прочее", поэтому Agile, спринты в 2 недели, есть тесты, нет тестов, забей.

Документация в таких промежутках либо не пишется, либо устаревает быстрее, чем пишется.

у меня у каждого теста есть метод prepare который заливает данные в нужнные сущнности и сохраняет в контекст теста. пайтест переписан, после коллекта всех тестов сначала вызываются все методы prepare, результат кладется в словарь в request.config по имени теста. Потом приходят тесты, достают контекст из конфига и выполняют проверки

копипаста решается выесением общей логики и наследованием

Так, хорошо, мои мысли двигаются в эту же сторону, пока что держусь на общих фикстурах и хелперах.
Проблема начинается тогда, когда данные приходят  не однородные:

Отправляем корректное поле, получаем 201 статус,  получаем тело
Отправляем некорректное поле, получаем 409 статус, получаем иное

Скорее всего, мне больше интересно как и где храните эти данные для заливки в prepare

я ж написал, запихиваю в request.config

ну точнее это для теста request.config, так как я это делаю на стадии коллекта, то данные кладу в session.config

щас пришлю псевдокод

Это обработка уже в процессе работы
Допустим, есть некоторый массив данных

Его же можно разделить на "входные данные" и "строгая входная структура" (надеюсь понятно выразился)
Вот тут больше вопрос по входным данным.

К примеру, есть эндпоинт /a, который принимает на вход {"a": int64}
Допустим, если клиент(для упрощения): client.a(data}

И вот тут начинаете писать тесты:

client.a({"a": int64})
client.a({"a": int32})
client.a({"a": float})
client.a('test')
client.a()

и т.д.

Вот каким образом и где хранить вот эти переборы структур?
Ну ладно, можно упростить и структуру строить в фикстурах, тогда где хранить значения входных данных?

Или я слишком сильно накручиваю костылей и говнопотока, если можно копипастить тесты и тупо хардкодить:

если int64, то .. , ..
если int32, то .., ...
если float, то .., ..

Вообщем, тут наверное тест дизайн уже подключается. Смотрел всякие проекты, однако либо это сэмплы, либо ребята вообще не заморчиваются, херачат 100 кейсов копипастой

Вот как выглядит тест
https://pastebin.com/AUbNZibq

Вот как это реализовано в conftest
https://pastebin.com/sN5zubt7

но опять же оговорюсь что мне это надо только потому, что мне нужно чтобы все тесты положили данные перед стартом тестовой сессии

client.a({"a": int64})
client.a({"a": int32})
client.a({"a": float})
client.a('test')
client.a()

масса вариантов, кажется тебе подойдет обычная параметризация

Спасибо! Буду разбираться...

Тогда наверное главный вопрос: эта параметризация сгребает все параметры. Мне нужно разделить позитивные и негативные сценарии?
т.е. 2 параметризации