Комментарии 19
у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL. Нужна in-memory БД
В теории выглядит хорошо, но на практике sqlite и postrgesql отличаются значительно. Если ваш проект не использует ORM, то тогда вы рискуете построить свой, чтобы тестировать «in memory db», а в проде работать в postgresql.
но что мешает в качестве In-Memory БД для PostgreSQL использовать PostgreSQL на базе testcontainers? крайне мало у какого нынешнего разработчика не найдётся Docker на компе
Суть вот в чём: у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL. Нужна in-memory БД. Вам всё ещё нужно проверять работоспособность интеграции с PostgreSQL, но для этого достаточно всего несколько тестов, а это заметное отличие!
Я пробовал писать тесты для Entity Framework именно с in-memory тестов. Оказалось, что с ним куча ограничений и майкрософт рекомендует переходить на более похожие на настоящие базы типа sqlite, посидев на них пришлось честно уползти на реальный MS SQL localdb.
Когда оказывается, что in-memory не ловит ограничения внешних ключей — вы потом сами захотите более медленные интеграционные тесты, чем какие-то быстрые, которые ничего не диагностируют.
В общем, у меня другой опыт использования.
В остальном статья хорошая, не сказать, что со всем согласен, но заставляет задуматься о правильных вещах.
Да и с опытом не всегда приходит. Чаще всего именно с опытными людьми идут споры о необходимости/излишестве интерфейсов в конкретных случаях. Вот мне лично до сих пор не ясно, нужны ли интерфейсы исключительно для тестов, особенно если средства языка и/или стандартной библиотеки позволяют мокать и без интерфейсов, пускай и через рефлексию или ещё какую магию.
Немного не понял про интерфейсы. В динамически типизированных их выделять не надо? Как по мне очень удобно с ними моки делать прямо в тестах анонимными классами. И на архитектуру хорошо влияет, если следование SOLID называть хорошим. Заметный такой звоночек о нарушении ISP, если постоянно в тестах мокаешь интерфейс, в котором большую часть методов совсем тупыми заглушками имплементируешь и нигде не проверяешь, просто чтобы зарабатало.
Суть вот в чём: у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL
Ну конечно, чтобы на бою ваше идеально оттестированое приложение с треском втыкалось в чеки и нарушения констрейнов?
Почему "чтобы"? Чтобы не втыкалось нужно интеграционное и функциональное тестирование.
Если вы используете моки, то вы хоть что-то тестируете?