Реализация команды установки нового пароля с проверкой текущего. Инъекция сервисов в метод. Тестирование зависимых объектов. Стабы и моки.
Скрытый контент
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Комментарии (7)
Arunas
Спасибо.
Arunas
падумал: нет ли возможность взять какой то кмпонент аутентификации из напр. Симфони и присвоит здесь как то?...
Дмитрий Елисеев
Да, возможно. Symfony-компоненты как раз могут использоваться сами по себе в любом проекте.
Sergei
Разница между стабом и моком понятно, но есть еще професи, и оно выглядит также как и стаб. Тогда в чем разница? Спасибо
Дмитрий Елисеев
Prophecy - это отдельный фреймворк.
В его описании есть примеры, как с его помощью делать стабы и моки.
Dmitriy
Много где слышал, что хорошей практикой является создание собственных классов исключений.
Почему вы не практикуете это?
Дмитрий Елисеев
Это удобно если есть необходимость их по-разному отлавливать и обрабатывать. Например, если мы пишем клиент для API, то в нём есть смысл делать свои отдельные ConnectionException и ResponseException, чтобы дать возможность отлавливать их разными блоками catch {}.
Или чтобы в тех же тестах или переводов указывать имена классов вместо текста:
В нашем же случае мы все доменные исключения будем отлавливать и отображать одинаково. Так что особой пользы добавление куч классов исключений нам не принесёт.
Спасибо.
падумал: нет ли возможность взять какой то кмпонент аутентификации из напр. Симфони и присвоит здесь как то?...
Да, возможно. Symfony-компоненты как раз могут использоваться сами по себе в любом проекте.
Разница между стабом и моком понятно, но есть еще професи, и оно выглядит также как и стаб. Тогда в чем разница? Спасибо
Prophecy - это отдельный фреймворк.
В его описании есть примеры, как с его помощью делать стабы и моки.
Много где слышал, что хорошей практикой является создание собственных классов исключений. Почему вы не практикуете это?
Это удобно если есть необходимость их по-разному отлавливать и обрабатывать. Например, если мы пишем клиент для API, то в нём есть смысл делать свои отдельные ConnectionException и ResponseException, чтобы дать возможность отлавливать их разными блоками catch {}.
Или чтобы в тех же тестах или переводов указывать имена классов вместо текста:
В нашем же случае мы все доменные исключения будем отлавливать и отображать одинаково. Так что особой пользы добавление куч классов исключений нам не принесёт.
Или войти через: