Laravel. Как очистить состояние приложения в процессе теста?
Здравствуйте!
Использую Laravel 8 + аутентификацию на sanctum api token. Пишу маршрутные тесты апишки по типу "чёрный ящик". Мои тесты ничего не знают о приложении кроме роутов, которые им доступны для действий.
Вот какая проблема получается. Когда тест собирает экземпляр приложения, он со временем накапливает в себе состояние, которое мне нужно очистить. Я "законным способом" создаю по экшенам пользователей, логиню их, совершаю различные действия и тд. Потом мне нужно проверить приложение от лица гостя, но тут встает проблема. У апи гварда санктума под капотом нет логаут метода. А очистка токена не помогает разлогинить пользователя. Тест лары держит в себе промежуточное состояние, в т.ч. и залогиненного пользователя. Я пытался использовать refreshApllication метод, но тогда у меня очищается база вместе со всем приложением.
Существуют ли какие-то способы очистить промежуточное состояние приложения, либо принудительно обнулить аутентифицированного пользователя? Я использовал перегрузку фасадов, это тоже не помогло.
PS я знаю про actingAs но это ломает тогда мой чёрный ящик и всю архитектуру таких тестов.
PPS если я уберу трейт RefreshDatabase тогда у меня пропадёт изолированность каждого теста, но не будет обновляться база при использовании refreshApplication. А подключить метод refreshDatabase в setUp без трейта вроде как уже невозможно в этой ларе.
Создавать среду для теста нужно в сетапе, а не в тесте.
Потом мне нужно проверить приложение от лица гостя
Это отдельный тест. В тесте должен быть короткий сценарий. Выстрелил - убил. А не научился стрелять, получил разрешение, купил ружье и тд Не нужно вести юзера от регистрации до удаления аккаунта с взаимодействием с другими сущностями и юзерами. Это бред. Много маленьких тестов, все повторы через итерацию dataProvider и очищать перед тестом, а не во время.
Здравствуйте. Спасибо за ответ, но вы ответили не та тот вопрос :)
Тестирование по стратегии "черный ящик" на то и называется чёрным ящиком, что единственное о чем я знаю в системе - это её маршруты. Сеялками и сетапами я уже раскрываю тестам детали бизнес логики системы. Плюс я должен быть на все сто процентов уверен что сеялка делает тоже самое что и создание через контроллер. А это значит что придётся лезть в реализацию.
Не спрашивайте почему я принял такую стратегию тестирования) Я себе отдаю отчет о всех минусах этой стратегии, но плюсы на порядок выгоднее для моих задач чем минусы.
Holmess88, знаю я эту стратегию. Говнокод чистой воды. Сам так делал. Потом все выкинул тк превратилось в неподдерживаемую кашу. Плюс мало на самом деле покрывает. Говорю почитай про dataProvider ими можно нормально так нагрузить тест со всех сторон с минимумом кода и без дублирования.
