tgoop.com/orgprog/395
Last Update:
Восстановление состояния в тестах
И так, вы решили написать тесты на свой проект. Вопрос, как добиться изоляции тестов друг от друга, когда речь идет про интеграционные и функциональные тесты?
Кто-то скажет, что все мокает и поэтому проблемы нет, реальный код изменяющий состояние, например, который ходит в базу, не вызывается. Это конечно выход, но цена у такого решения оч высока, а качество проверки сильно хуже у чем у тестов, которые вызывают реальный код.
Другой подход, в том, что позволять коду выполнять практически все внешние взаимодействия, кроме пожалуй, обращения к внешним сервисам, это точно должно быть запрещено, как минимум по причинам связанным с безопасностью и повторяемостью.
Но, тогда сразу встает вопрос, если один тест что-то изменил в базе, то как это повлияет на остальные тесты? Обычно влияет хреново, даже на небольшом наборе тестов. Допустим есть тест на регистрацию пользователя. Мы запускаем этот тест второй раз и он падает с ошибкой, потому что такой пользователь уже создан. Можно попытаться все время создавать новые данные, но это доп сложность (я не видел примеров где бы это было реализовано в полной мере). Можно попытаться чистить данные после каждого теста. Тут две проблемы. Во-первых этот код может не отработать если возникли ошибки в процессе (зависит от фреймворка и того как написано), а во вторых, это огромная когнитивная нагрузка, настолько большая, что программисты будут избегать писать тесты, лишь бы не думать об этом и не бороться потом с багами из-за забытых данных.
Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).
Поработав в таких системах вопрос о том надо ли мокать даже не встает. Без моков работает и проще и надежнее и понятнее. Да тут возможна история с производительностью, но про это будет отдельный пост фабрики vs фикстуры.
Ссылки: Телеграм | Youtube | VK
p.s. Как у вас? Мокаете или реальная база с откатом?
BY Организованное программирование | Кирилл Мокевнин
Share with your friend now:
tgoop.com/orgprog/395