vism, я паттерны не изучал. Классы использую по необходимости, которая возникла (читаемость и рефапкторинг сложной логики). Способ исполнения постоянно где-то видел, видимо это самое простое и массовое использование классов у разработчиков. Для меня сработало. Без классов при сложной логике начинались проблемы. Нужно было вникать. Сейчас не нужно – открываешь файлы и исправляешь. Практически нет вариантов ошибиться и перепутать. Других примеров и чтобы также просто не встретил. Но я плохо искал)
NubasLol, ну я не пишу сейчас тесты для покрытия. Покрывать существующий функционал это гемор. Я делаю их для разработки. Вот смотри например сделать раздел где добавляются ссылки соцсетей с учетом что должны быть ссылки и только указанных соцсетей в полях под нужные языки с разным уровнем доступа для разных юзеров. Если без тестов делать это задалбаешься проверять руками. Различные авторизации заполнения и т.д. Там тьма вариантов, которые могут у юзера на проде всплыть. А так вначале напишешь тесты строчек на 300, потратишь 1,5ч т.к. они простые, однообразные и пишутся быстро (я пишу только Feature). Опишешь там все основные расклады - а юзеры бывают глупые или хитрые. И можешь к форме вообще не обращаться руками. Запускаешь тесты и разрабатываешь начиная с роута пока они не станут зеленые. Т.е. и разработку ускоряют и как детальное тз (пока пишешь куча новых идей приходит) и на будущее остаются для проверки. Ну и результат более качественный
У меня в процессе авторизации своя логика (типы юзеров, редиректы, уведомления и т.д.) плюс тех-моменты (капча, спам, типы запроса). Все покрыто тестами во всех вариациях т.к. я вначале пишу тесты, а потом фичу. Мне так удобней разрабатывать, дебажить и в тестах более полно формулирую тз и че хочу. И тесты не дадут схалявить и что-то забыть. Так по всему приложению. Правда код тоже в тестах дублирую и поэтому они длинные т.к. имхо ими так проще пользоваться.
Константин Б., NubasLol, признаю был не прав. Я имел ввиду сделать LoginRequest и подготовить данные в методе prepareForValidation. Но в Laravel username() используется в разных местах и его в любом случае менять поэтому определять емейл/логин в валидации смысла нет
NubasLol, даже если в одном поле (хотя в задаче такого нет) – какой смысл делать вне валидации? Делай user rule, required if возвращай ошибки через message, тестируй через jsonValidationErrors. Какая причина не использовать все эти решения?
NubasLol, если изменять поля в дфеолте нужно переписывать валидацию и все обращение к username. Писать кастомные Rule и делать нужные проверки с возвратом сообщений об ошибках. или есть лучше способ?
NubasLol, ты тестировал эти варианты? Я нет. Сомневаюсь, что Ларавел что-то там проверяет. Он проверяет судя по всему username, ожидая что там будет email.
NubasLol, да там куча вариантов. Как минимум чтобы проверить есть такой емейл если емейл. Обычно на тестах туча вариаций, связанных с валидацией. Плюс как обслуживать все эти изварщения, в смысле сообщения и т.д. Ты тоже чтоли формы не валидируешь?)