Pull to refresh

Comments 19

у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL. Нужна in-memory БД

В теории выглядит хорошо, но на практике sqlite и postrgesql отличаются значительно. Если ваш проект не использует ORM, то тогда вы рискуете построить свой, чтобы тестировать «in memory db», а в проде работать в postgresql.

Вы не путаете ORM и DBAL?


И вообще, in memory db вовсе не означает, что какой-то sqlite нужно тянуть. Это может быть просто массив или хэшмэп в памяти

UFO just landed and posted this here

но что мешает в качестве In-Memory БД для PostgreSQL использовать PostgreSQL на базе testcontainers? крайне мало у какого нынешнего разработчика не найдётся Docker на компе

Так и живём. Только я слышал мнение, что это нельзя назвать юнит тестированием. Хотя по мне хоть мартышкой назови, главное, чтобы работало и делало своё дело.

так, с in-memory на sqlite тоже не будет юнит-тестом...

Суть вот в чём: у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL. Нужна in-memory БД. Вам всё ещё нужно проверять работоспособность интеграции с PostgreSQL, но для этого достаточно всего несколько тестов, а это заметное отличие!

Я пробовал писать тесты для Entity Framework именно с in-memory тестов. Оказалось, что с ним куча ограничений и майкрософт рекомендует переходить на более похожие на настоящие базы типа sqlite, посидев на них пришлось честно уползти на реальный MS SQL localdb.


Когда оказывается, что in-memory не ловит ограничения внешних ключей — вы потом сами захотите более медленные интеграционные тесты, чем какие-то быстрые, которые ничего не диагностируют.


В общем, у меня другой опыт использования.


В остальном статья хорошая, не сказать, что со всем согласен, но заставляет задуматься о правильных вещах.

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

На словах то все это понимают… Вот бы реальные примеры, а не бла бла… Но зато такую статью можно показать манагеру который топит за скорость.
Вопрос к автору: не считаете ли вы, что куча интерфейсов на каждый чих лишь усложнит систему, а не упростит?
Интерфейсы усложняют систему, что бы упростить ее изменения. Яное дело, их не нужно плодить «на каждый чих», только где необходимо, а вот ответ на вопрос «где\когда необходимо» приходит уже с опытом.

Да и с опытом не всегда приходит. Чаще всего именно с опытными людьми идут споры о необходимости/излишестве интерфейсов в конкретных случаях. Вот мне лично до сих пор не ясно, нужны ли интерфейсы исключительно для тестов, особенно если средства языка и/или стандартной библиотеки позволяют мокать и без интерфейсов, пускай и через рефлексию или ещё какую магию.

Моки (как и все) имеют место на жизнь, если их грамотно использовать, в случае модульных или тестов, на сложные сервисы. Главное чтобы замоканный компонент должен быть 100% покрыт юнит тестами. А еще лучше, когда мокается самый нижний уровень, например в случае тестирования сервисов, которые отправляют запросы на внешний сервис, можно подставить сам ответ (json, XML), словно мы выполнили запрос и получили ее в ответ.

Немного не понял про интерфейсы. В динамически типизированных их выделять не надо? Как по мне очень удобно с ними моки делать прямо в тестах анонимными классами. И на архитектуру хорошо влияет, если следование SOLID называть хорошим. Заметный такой звоночек о нарушении ISP, если постоянно в тестах мокаешь интерфейс, в котором большую часть методов совсем тупыми заглушками имплементируешь и нигде не проверяешь, просто чтобы зарабатало.

Суть вот в чём: у вас должна быть возможность тестировать все виды поведения вашего приложения без сохранения данных в PostgreSQL

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

Почему "чтобы"? Чтобы не втыкалось нужно интеграционное и функциональное тестирование.

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

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

Sign up to leave a comment.