стандартной аутентификации/регистрации через Laravel?
Мне просто нужен именно пример.
Готовых под рукой нет, но принцип у них простой: - в unit проверяешь классы - в feature - запросы В таких случаях я обычно делаю 4 теста на каждый метод: 1. Отправляю правильные данные, жду правильные данные, проверяю что записалось в базу. 2. Отправляю неправильные данные, ожидаю дроп ошибки валидатора, сверяю содержимое валидатора. 3. Отправляю пустые данные, ожидаю дроп ошибки валидатора, сверяю содержимое валидатора. 4. Повторно отправляю правильные данные из пункта 1 с целью отлова ошибок дублирования данных (при регистрации, например). В юнит-тестах проверяешь обращения к методам, а в feature через реквесты. По сути, те же яйца видом сбоку.
Данные фейковые под бд для юнит-тестов, верно?
По идее для тестов разницы нет, но у себя фейковые использую
Те 4 пункта, которые ты описал — они же к feature-тестам относятся? У меня такое ощущение сложилось, потому что мы тут работаем не напрямую с методами login/register/verify/etc, а просто отправляем разные варианты данных (валидные, невалидные, етс) и убеждаемся, что ответ ожидаемый для этого сценария
По сути ко всем тестам. В них не только успех нужно покрывать, но и "падения". Например, вот: https://github.com/TheDragonCode/support/blob/5.x/tests/Helpers/Http/Builder/GetBaseDomainMethodTest.php То есть, тесты должны покрывать то, что отвечает на вопросы: 1. Что будет, если всё ок? 2. Что будет, если повторить отправку данных, т.е. попытаться создать дубликат? 3. Что будет, если отправить заведомо кривые данные? 4. Что будет, если отправить пустую форму? Данный список вопросов, само собой, не избыточен, но направление понимания задаст верно.
> У меня такое ощущение сложилось, потому что мы тут работаем не напрямую с методами login/register/verify/etc По сути да
это ответило на все мои вопросы, спс
Обсуждают сегодня