опыт как организовать нормальные функциональные тесты? Хочется вызвать grpc метод, проверить его ответ и быть уверенным что в базе на каждый тест будет лежать ожидаемое состояние. Есть ли какое нибудь готовое решение, чтобы подсовывать приложению тестовую базу с фикстурами и очищать её на каждый тест?
Посмотри gonkey
В нем можно закладывать фикстуры так же смотреть ожидаемый результат, и готовый. МОК нас grpc не могу сказать http client точно можно замокать
Смотрел, даже законтрибьютил туда фикс багулины, вопрос в том, что он не нужен целиком, а хочется реализовать только функциональность связанную с базой
Я правильно понял, что это задать initial state в бд, запустить тест, и чекнуть результат. И почистить бд?
Задача со звездочкой, научиться делать это в докере, запускаемом girlab-ci
https://pkg.go.dev/github.com/stretchr/testify/suite Практиковал вот такое, Создаем структуры с Необходимым инстанс с хранилищем, готовим фикстуру, Миграцию если необходимо. Потом готовим, service/usecase который проверяем, по желанию если есть external service, можно из gonkey моксервис взять, Что то в таком духе
это у вас синдром питона, фикстуры там) но я вам понимаю, тоже использую testify и называю их фикстурами))
В то время мои знания по питону, подключаю СДК нейронки написаную на C и передаю ей бантики 😭
Вот + статья с примером
А мне иногда не понятно зачем проверять, что сохранили. Можно протестировать контракты на каждом уровне, У меня все покрыто тестами. Кроме репозитория или cqrs. Вопросы встают вот такие: 1. зачем тестировать как мы сохранили в бд? 2. Что будет если поменяется хранилище с sql на no sql?
У меня тестируется имплементация репозитория. поменяется репозиторий - напишутся к нему новые тесты
Зачем писать миллион моков которые завязаны на реализации если можно положить в базу состояние и проверить ожидаемый ответ в ручке? Для no sql просто поменется нижний уровень который фикстуры подкладывает в базу
А что тогда тестирует тест? он тетсирует функцию? или базу? А если ошибка, то в каком месте? такой подход ломает принцип single responsibility
Тест проверяет функциональное требование к микросервису, что контракт выполняется на наборе данных в заданном окружении
Обсуждают сегодня