Молодые люди, подскажите по интеграционным тестам репозиториев в phpunit
Сейчас делается так:
Поднимается контекст приложения, заливается в бд sql с предподготовленными данными
Есть методы теста которые тестирую методы репозитория на выборку
Я дергаю метод и получаю энтити
Как мне проверять поля этой энтити? Забивать хардкодом в тест? но ведь потом если нужно будет поменять что то, то это и sql править и тест, адекватно ли это?

1. Если ты тестируешь репозиторий - непонятно зачем заливать sql с предподготовленными данными. У репозитория есть определённый интерфейс.
2. А зачем тебе проверять поля энтити? Почему тебя в контексте тестирования репозитория интересует какие именно поля у энтити?

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

1) Заливать предподготовленный sql потому что у репозитория есть только на выборку методы и мне нужно их проверить
Проблема в дикой не нормализованной структуре бд. Мы отделяем код работы с базой от бизнес логики. По проекту ходят адекватные энтити, а в репозиториях куча логики по преобразованию этого на структуру бд и обратно.
2) Ну так мне же нужно проверить что именно было выбрано, а что тогда тестировать в репозитории?
Я говорю, там например findEntityById(1)
А внутри репозиторий может хоть в 2 таблицы полезть что бы выборку реально по айди сделать и склеить резалтсеты, т.к. бд в ужасном состоянии
И мне нобходимо проверить, что каждое поле является верным для выборки энтити с айдишником 1

1. Я бы попытался сделать метод для добавления и избавился от sql. Или вообще не тестировал бы репозитории такими тестами. Пофиг в принципе что там нормализовано или ненормализовано. У тебя есть интерфейс, который говорит о том, что если ты добавил энтити, то при поиске через вот этот метод - должен её и получить. Как оно это сделает - неважно.
2. А как ты проверяешь эквивалентность двух объектов в коде?
В репозитории тестировать соответствие реализации интерфейсу. Если интерфейс говорит, что ты должен получить то же, что и добавил(а в случае с репозиторием это обычно так и есть) - значит надо это проверить.

Я в тестах новичок и меня мучает вопрос яйца и курицы, т.е. мне что бы протестить вставку необходим уже протестированный метод выборки, а выборку я не смогу протестить ничего не вставив в бд
Как быть в этом кейсе?

вставь что-то в бд...

вставлю, но как мне проверить что вставка произошла корректно?

в смысле? она априори прошла корректно, если ты не получил в лоб эксепшен

Делаешь дата фикстуры и тестишь на них, в чем трабл?

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

нет, не могут.

ошибка в именовании полей = эксепшен

еще раз: если ты не получил эксепшен, данные вставились и точка. Даже не спорь

есть 2 поля
img1 и img2
я в коде перепутал при вставке и вставлял значение img1 из энтити в поля бд img1 и img2
т.е. физически ошибки нет, но данные вставились некорректно
реальный, недавний кейс

так ты выборку тестируешь или вставку?

Можно написать другой тест (например тест апи или что там у тебя). А дальше рефакторинг. Добавить метод добавления в репу и посмотреть, что ничего не сломалось.
ХЗ, тесты в легаси - это сложно. Мне кажется (но я не эксперт) что лучше начинать с позитивных тестов, которые дадут тебе какую-то уверенность, что в целом в самых важных случаях всё работает.

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

в тесте на выборку ты тестируешь выборку, если ты проебешься с названием поля - значит либо это покрыто твоим тестом на выборку, либо это не имеет значения для этого теста

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