Всем привет! Мне говорят, что в тестировании существует такая практика,

что если используется непредсказуемый айди, то в фикстурах вместо реальных айди используется AUTO, и тестирующая программа потом заменяет сама AUTO на айди созданного объекта (тест получения объекта по айди, загружается фикстура из файла в словарь, в словаре заменяется). Это так, или есть способ получше?

А данные потом в реляционную бд загружаются?

Конечно. Для тестов создаётся база данных, после тестов удаляется, для каждого объекта набор тестов на создание, получение списка, получение по айди, изменения, удаления в рамках одной бд.

Я обычно держу актуальный sql-дамп для этого, в insert можно пропускать значения sequence-полей например, фикстуры в виде json уже некий архаизм на мой взгляд

Ну даже если так, это не решает моей проблемы (:

Нет json, нет проблем)

Это абсолютно не решает проблему получения объекта по айди, ведь он неизвестен до запуска теста. У меня есть такой вариант: в фикстурах специальное значение заменять нужным айди до проверки теста, но я спрашивал, есть ли вариант получше, так как немного похоже на хак какой-то, хоть мне и говорят, что нормальная практика

Можно пожалуйста пример тестов, где требуется id, который неизвестен притом

https://github.com/bitcartcc/bitcart/blob/master/tests/fixtures/data/users.json#L74

Ммм...свой тестовый фреймворк поверх пайтест? Ну наверно успехов тогда

Сказать что это плохо это конечно хорошо. А предложить альтернативу? Это не тулинг, а просто миксин для упрощения тестирования схожих endpoint'ов, данные задаются в таком формате. Что не так?

Выкинуть async/await из тестов, выкинуть, gino, заюзать sqlalchemy, выкинуть декларативные описание кейсов в json, чем классические ассерты не угодили не понятно, тестируемые сущности оформить в виде датаклассов, ...

Чем классические ассерты не угодили? Ну там просто у разных объектов все повторяется, endpoint'ы по одному шаблону, поэтому и для тестов шаблон. Хотя возможно parameterize просто сделать? Выкинуть async/await из некоторых тестов нельзя, так как они как раз и тестируют асинхронные функции Выкинуть gino и взять sqlalchemy - поддержка асинхронщины там бета, и все решения, которые только могли быть, я уже пробовал, поэтому позже сделаем

1.4 вышла уже из бэты

1.4 вышла, я говорю про поддержку асинхронщины. С версии 1.4.3 она только в бету перешла, еще может меняться и не очень стабильно все

Из асинхронного увидел обращения к бд, ну тут видимо вы не хотели использовать sqlalchemy sql expression syntax, и сделали все через gino, ещё использовали асинхронный хттп клиент, хотя вроде есть синхронная альтернатива, ещё обращения к редису, к каким-то объектам очередей и т.п. Пробежался в целом по проекту, не увидел необходимость в использовании эвент лупа. Все равно корутины будут ожидать освобождение коннекта из пула, и все преимущества нивелируются, может я чего-то не понимаю конечно

Не хотел использовать sqlalchemy syntax? (: А gino это что?) Это sqlalchemy core и диалект для asyncpg, ничего больше. Так что алхимия и алембик так или иначе используется. У нас сторонние сервисы, к ним сдк асинхронное. А вообще просто большая часть времени как раз на I/O тратиться, поэтому тоже асинхронно. Менять мы уже точно не будем, нет смысла Вряд ли можно большой проект понять, быстренько просмотрев (: Но спасибо за предложения улучшений и потраченное время)

Аналогия с Gino - это как использовать pandas или numpy, и говорить что пишешь на C :) не за что, обращайтесь :)