Как тестировать insert-ы в базу?

Question

[Северное Сияние]

Есть тесты, которые грузят в базу данные - это один вид тестов.
Соответственно, в этом же классе надо сделать какие-то проверки, например, сколько записей добавлено:

function testUpdate(){}

function testCountRows(){}

При этом базу не надо захламлять - надо как-то очищать.
Трейт ларавела DatabaseTransactions выполняется на каждом тесте (методе) и это не решение - метод testCountRows уже ничего не покажет, произойдет откат транзакции.

Как поступить правильно?

Comments

[JhaoDa]

Считай в той же транзакции в методе testUpdate().

[Андрей]

Правильно - не тестировать работу с БД

[DevMan]

Андрей, фигасе новость.

[Андрей]

DevMan, не, может в Laravel такое принято, но во всём остальном мире бд мокают и тестируют бизнес-логику, а не библиотеку для работы с БД и не саму БД.

[Алексей Уколов]

Андрей, в разы проще ничего не мокать, а просто посмотреть в таблицу. Так и во всём остальном мире часто делают. Усложнять тесты ради пуританизма с неочевидной пользой — это остаться без тестов.

[Алексей Уколов]

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

[DevMan]

Андрей, может у вас и иначе, но везде, где я работал, "тестировать работу с БД" и "мокают и тестируют бизнес-логику, а не библиотеку для работы с БД и не саму БД" – тождественные понятия.

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

[Андрей]

DevMan, вся работа с БД должна быть абстрагирована от основного кода, и в тестах должна подменяться на реализацию, работающую с коллекциями.
Единственный разумный вариант использования БД в тестах - нагрузочное тестирование. В остальных случаях это либо лишнее переусложнение (своя БД на каждый тест), либо загрязнение тестов и опять же переусложнение (одна БД на все тесты - могут возникать ошибки из-за результатов предыдущих тестов, нужно очищать данные предыдущих тестов).
Ну а так - я не спорю, что такой вариант есть и пользуется популярностью. Я лишь хочу сказать, что это не лучший выбор, лучше сразу сделать правильно.

[DevMan]

Андрей, должна, не значит есть.
и если даже есть то не тестировать бд и использовать моки - не одно и то же.

[Северное Сияние]

Алексей Уколов,

А что же вы тогда проверяете в testUpdate

загрузка файлов с данными

[Алексей Уколов]

Что «загрузка»? Как вы в тесте проверяете, что функционал работает?

[Северное Сияние]

Алексей Уколов, ответ от api 200й

[Алексей Уколов]

Вот там же нужно проверять и то, что данные реально были обработаны и сохранены. То, что приложение не упало, ещё не значит, что всё работает как надо. А выносить проверку в отдельный тест — это очень странно.

[Северное Сияние]

Алексей Уколов,

А выносить проверку в отдельный тест — это очень странно.

а как быть?

[Алексей Уколов]

Десять человек уже тут написали — проверять содержимое БД нужно в том же тесте, который данные создаёт. И тогда вопрос очистки или неочистки БД вообще не будет стоять. Arrange, Act, Assert.

Answer 1

[Константин Толмачев]

https://laravel.com/docs/5.8/database-testing
+ Можно сказать чтобы он не пересоздавал после каждого теста

Answer 2

[jazzus]

не тестировать в разных методах, связанные процессы. Тесты должны быть независимы, иначе на результат будут влиять предыдущие тесты и поддержка зависимостей между ними. setup класса позволит задать стартовые настройки.

При этом базу не надо захламлять

RefreshDatabase трейт.

Comments

[Северное Сияние]

RefreshDatabase трейт очищает каждый раз. Мне это не подходт

[jazzus]

Северное Сияние, и? Model::truncate()?) Я могу еще методы накидать, как удалять данные.

Мне это не подходт

То как правильно то не подходит. Правильно делать тесты изолированными. Завязываться на бд, предыдущих тестах это всегда ловить геморой и тратить время на дебаг с ростом тестов.