Реализация команды установки нового пароля с проверкой текущего. Инъекция сервисов в метод. Тестирование зависимых объектов. Стабы и моки.
- 00:00:38 - Постановка задачи
- 00:02:52 - Команда смены пароля
- 00:03:35 - Подход с внешними проверками
- 00:05:36 - Инкапсуляция операции в сущности
- 00:06:56 - Unit-тесты для метода changePassword
- 00:07:39 - Тестовая реализация для интерфейса
- 00:08:23 - Заглушка для класса
- 00:09:17 - Механика создания стабов в PHPUnit
- 00:12:50 - Если бы тестировали команды
- 00:14:53 - Отличие моков от стабов
- 00:17:40 - Вынос создания стаба в метод
- 00:18:11 - Тест для некорректного пароля
- 00:18:33 - Тест для пользователя из соцсети
- 00:19:32 - Доработка UserBuilder
- 00:21:51 - Реализация метода changePassword
- 00:22:43 - Оптимизация метода сброса пароля
- 00:23:14 - Необходимость проверок в API
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо.
падумал: нет ли возможность взять какой то кмпонент аутентификации из напр. Симфони и присвоит здесь как то?...
Да, возможно. Symfony-компоненты как раз могут использоваться сами по себе в любом проекте.
Разница между стабом и моком понятно, но есть еще професи, и оно выглядит также как и стаб. Тогда в чем разница? Спасибо
Prophecy - это отдельный фреймворк.
В его описании есть примеры, как с его помощью делать стабы и моки.
Много где слышал, что хорошей практикой является создание собственных классов исключений. Почему вы не практикуете это?
Это удобно если есть необходимость их по-разному отлавливать и обрабатывать. Например, если мы пишем клиент для API, то в нём есть смысл делать свои отдельные ConnectionException и ResponseException, чтобы дать возможность отлавливать их разными блоками catch {}.
Или чтобы в тех же тестах или переводов указывать имена классов вместо текста:
В нашем же случае мы все доменные исключения будем отлавливать и отображать одинаково. Так что особой пользы добавление куч классов исключений нам не принесёт.
UserBuilder не настроит active статус у юзера из соцсети, возврат раньше происходит.
Добрый день, подскажите если не трудно, какое лучшее решение для теста сущностей с индефикатором через обычный автоинкрементный id ? мне подход uuid понравился, но команду не всегда убедишь в продакшене такое использовать, а тесты писать хочется)
Если работаем с PostgreSQL, то можно сделать отдельную секвенцию и через репозиторий доставать инкрементный идентификатор из неё:
и подставлять при создании этот числовой id:
То есть сделать числовой идентификатор и заполнять из секвенции.
А в MySQL можно эмулировать секвенцию отдельной таблицей с одним полем:
и в репозитории делать вставку туда записи с id=NULL и брать lastInsertId.
Либо смириться и id не тестировать.
понял, спасибо за ответ
Можно рефлексию в юнит тестах заюзать для принудительного проставления ид в сущности.
Нет никакой пользы делать это только в тестах.
Или войти через: