Comments 5
Если вы используете dependency injection, то вполне уже можете изолироваться от базы данных каким-нибудь интерфейсом. При этом необходимость писать "собственный PostgreSQL для тестов" немедленно отпадает. Для тестов нужно будет всего лишь сделать реализацию этого интерфейса, которая будет оперировать данными в памяти.
Модульные тесты на Python-е я писал году примерно в 2001-ом. Никаких особых сложностей вроде не возникало. Наоборот, если сравнивать скажем с тогдашним ASP.NET-ом и C#-ом, то все получалось легко и ненавязчиво. Любую реализацию для тестов можно подменить своей собственной, в силу динамической типизации Python-а.
pytest смотрели? Он конечно полон магии и колдунства, а в код внутри лучше не заглядывать, но после него на обычные xunit фреймворки смотреть не хочется.
потому что SQLite работает с файловой системойСправедливости ради можно отметить www.sqlite.org/inmemorydb.html
Для sqlite3.connect исполузуется псевдо-путь :memory: достаточно быстрая штука, иногда используется для организации внутреннего кэша.
В sqlalchemy(«sqlite://») и django(":memory:") для не сложных проектов, не использующих специфичные типы данных и операции, вполне применимо для тестов. Для специфичных тестов можно использовать skipIf или маркировку, например pytest.mark.pg, и запускать такие тесты в отдельном окружении.
Не стесняйтесь использовать в тестах зависимости. В этом нет ничего плохого. Если вы подняли memcached, потому что без него ваш код нормально не функционирует, ничего страшного.
Почему нельзя просто замокать обращение к memcached? Если это в каком-то месте сложно сделать, то, кажется, это проблема в качестве тестируемого кода
Sign up to leave a comment.
Модульное тестирование и Python