TGViewer
Организованное программирование | Кирилл Мокевнин Организованное программирование | Кирилл Мокевнин @orgprog · 14.3K subscribers
Post #395 11.2K
Восстановление состояния в тестах

И так, вы решили написать тесты на свой проект. Вопрос, как добиться изоляции тестов друг от друга, когда речь идет про интеграционные и функциональные тесты?

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

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

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

Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).

Поработав в таких системах вопрос о том надо ли мокать даже не встает. Без моков работает и проще и надежнее и понятнее. Да тут возможна история с производительностью, но про это будет отдельный пост фабрики vs фикстуры.

Ссылки: Телеграм | Youtube | VK

p.s. Как у вас? Мокаете или реальная база с откатом?
Telegram Организованное программирование | Кирилл Мокевнин Делюсь опытом и обучаю. И ИИ? И ИИ. Ютуб https://youtube.com/@mokevnin AI Клуб @hexletclub | Внедрение AI в SDLC https://praxor.ru/ Для предложений в личку канала
  • 👍 47
  • ❤ 15
  • 🔥 10
  • 🤔 2
More from @orgprog
  1. Oct 1, 2026Статистика по задачам. Как повлиял ии? Заметил интересный эффект. По мере внедрения агенто…
  2. Sep 29, 2026Плановое обслуживание кода Даже если вы настроили у себя процесс разработки, в котором все…
  3. Sep 27, 2026Выпуск опубликован, можно смотреть и слушать. Сегодня в подкасте создатель Вастрик Клуба В…
  4. Sep 26, 2026Костные наушники Под каждым видео коммент, что за наушники ты носишь? Это костные наушники…
  5. Sep 24, 2026Статистика участия в опенсорсе Активно разрабатывая я регулярно наыткаюсь на баги и не дор…
  6. Sep 21, 2026Банда четырех для эпохи агентов Количество паттернов по тому, как эффективно работать с ИИ…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →