Написание и тестирование контроллеров

Спасибо за урок, Дмитрий!

У меня есть вопросы:

1) Не удобнее было бы в тестах использовать отдельную базу данных для тестового окружения? Тогда после тестов не пришлось бы опять накатывать фикстуры.

2) При использовании контроллера вне изолированных контекстов бывают сценарии, когда есть необходимость вызвать несколько интеракторов из разных контекстов (по событию или же через "оркестратор"). Есть ли один из них при этом успешно модифицировал данные, а следующий выбросил исключение, следует откатить действие первого. Планируется ли рассмотреть подобный сценарий?

3) Планируется ли рассмотреть Graphql для озвученной в видео возможности чтения запрашиваемых клиентом дополнительных данных у эндпойнта?

пересмотрел -> большое спасибо.

Попробую сформулировать свой вопрос.

Допустим, что у нас появилась необходимость из модуля блог дернуть авторизацию. То как то правильно сделать, чтобы не напрямую дергать код из авторизации? Чтобы модули не были напрямую зависимы друг от друга.

Надо как то дергать контроллер? Надо вводить какую - то абстракцию для этого?

Когда ту же авторизацию вынесут на отдельный сервер из -за нагрузки, допустим, то код просто исчезнет из нашей кодовой базы и надо будет как - то переключить вызовы на другую апи. Как это все реализовать правильно, чтобы не было потом больно? Как абстрагировать свои внутренние вызовы, чтобы потом можно было просто все поправить в одном месте?

Спасибо за уроки! Появилось два вопроса:

1) Если представить такую ситуацию. Нам необходимо вынести модуль Auth на отдельный сервер, когда производится аутентификация через OAuth2, токены для пользователя записываются в БД, которая отдельная/своя для модуля Auth. А как пользователь с этим токеном сможет достучаться до модуля Auction, если у него другая БД? Нам нужно при получении пользователем токена в микросервисе Auth отправлять его еще и в микросервис Auction и остальные микросервисы, лежащие на разных серверах с разными БД например через очередь? Или для такого используют другой подход?

2) Должен ли модуль Auth знать о доменных ролях? На например пользователь регистрируется на сайте и может иметь роль автора блога, либо читателя блогов и при регистрации он должен указать в качестве кого он хочет зарегистрироваться. Или модуль Auth будет иметь только роли ROLE_ADMIN, ROLE_USER. А роли ROLE_AUTHOR, ROLE_READER будут уже внутри модуля Blog, и будут выступать в виде сущностей Author и Reader?

Добрый день, Дмитрий!

Подскажите, пожалуйста, как лучше реализовать собственные обработчики ошибок 404 и 405 взамен тех, что существуют в Slim по умолчанию и возвращают ответ в формате HTML. В частности, необходимо на любые запросы к API (правильные или ошибочные) всегда возвращать свой ответ в формате JSON.

Не могу понять, мне выдает что

[2020-10-03T07:44:30.370415+00:00] API.ERROR: Entry "App\Http\Action\RequestAction" cannot be resolved: Entry "App\Auth\Command\JoinByEmail\Request\Handler" cannot be resolved: the class is not instantiable

routes:

return static function (App $app): void {
    $app->get('/', HomeAction::class);
    $app->post('/v1/auth/join', RequestAction::class);
};

Handler.php

class Handler
{
    private UserRepository $users;
    private PasswordHasher $hasher;
    private Tokenizer $tokenizer;
    private Flusher $flusher;
    private JoinConfirmationSender $sender;

    private function __construct(
        UserRepository $users,
        PasswordHasher $hasher,
        Tokenizer $tokenizer,
        Flusher $flusher,
        JoinConfirmationSender $sender
    ) {
        $this->users = $users;
        $this->hasher = $hasher;
        $this->tokenizer = $tokenizer;
        $this->flusher = $flusher;
        $this->sender = $sender;
    }

    public function handle(Command $command): void
    {
        ...
    }
}

Не понятно, что в нём не может зарезолвится, помогите пожалуйста

Здравствуйте Дмитрий! Спасибо за вашу работу, все реально доходчиво и полезно!
Столкнулся с такой проблемой при написании RequestAction:

Тесты все проходят - создается пользователь, отправляется письмо, если не очищать базу то повторно тест не проходит возвращается ошибка что пользователь уже есть - в общем все работает так как в тестах предусмотрено. При отправке запроса:

    POST localhost:8081/v1/auth/join
    Accept: application/json
    Content-Type: application/json
    
    {
     "email": "new-user-1@app.test",
      "password": "new-password"
    }

с невалидными данными возвращаются ошибки валидации, но если отправить этот запрос с правильными (валидными) данными ожидается что если базу не чистить вернется ошибка Пользователь есть или будет создан Пользователь по запросу и вернется пустой JSON - но ответ не ожиданный:

    {
      "message": "Slim Application Error",
      "exception": [
        {
          "type": "Doctrine\\DBAL\\Exception\\DriverException",
          "code": 0,
          "message": "An exception occurred in driver: could not find driver",
          "file": "/app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php",
          "line": 102
        },

Это получается что у меня при вызове контроллера RequestAction не видно Doctrine? Какая то ошибка в путях? Но тогда и тесты по идее не должны проходить! Буду очень признателен если поможете с решением этой проблемы! Спасибо!

Ребята, кто дошел до этой темы разрабатывая на Винде, пожалуста поделитесь, как вы собрали своё окружение разработки (vagrant, virualbox PhpStorm). Дошел с бубном до 10го урока и сдался, 10 уроков не разработкой занимался , а ДевОпс-ом у себя работал. На линукс пытался переехать, но и там не всё просто :)

Почему делаем Фикстуру для каждего реквеста, а не просто создадим один класс UserFixture с кучей методов "load_что_нужно" ?

Здравствуйте, Дмитрий! Хорошие впечатления получил от вашей серии уроков -- особенно по девопсу и тестам -- таких как вы по пальцам пересчитать )

Хотел спросить про тестирование контроллеров. На первый взгляд все просто -- формируй клиента, стучись в эндпоинт, ожидай, что произвелись нужные изменения и/или вернулось корректное состояние.

Но вот незадача, если в этом эндпоинте происходит работа с брокером сообщений через тот же Messenger в Symfony с использованием RabbitMQ.

Вот как здесь производить тестирование ? Есть ли какие-нибудь источники, на которые можно было бы ориентироваться при написании таких тестов ?

Я сам нашел вот этот источник: https://codeburst.io/unit-functional-test-the-symfony4-messenger-9eef328dce8 Правда здесь скорее описывается интеграционный тест, нежели функциональный

А хотелось бы также написать функциональные тесты для такого рода эндпоинтов, в которых используется брокер сообщений. Буду очень признателен за любую информацию!)

Вот на этом месте я сломался )) Если раньше почти все получалось, то сейчас упорно тесты не проходят, и понять почему я не смог...

There were 5 failures:

1) Test\Functional\V1\Auth\Join\RequestTest::testNotValid
Failed asserting that 404 matches expected 500.

/app/tests/Functional/V1/Auth/Join/RequestTest.php:65

2) Test\Functional\V1\Auth\Join\RequestTest::testSuccess
Failed asserting that 404 matches expected 201.

/app/tests/Functional/V1/Auth/Join/RequestTest.php:32

3) Test\Functional\V1\Auth\Join\RequestTest::testMethod
Failed asserting that 404 matches expected 405.

/app/tests/Functional/V1/Auth/Join/RequestTest.php:22

4) Test\Functional\V1\Auth\Join\RequestTest::testExisting
Failed asserting that 404 matches expected 409.

/app/tests/Functional/V1/Auth/Join/RequestTest.php:43

5) Test\Functional\V1\Auth\Join\RequestTest::testEmpty
Failed asserting that 404 matches expected 500.

/app/tests/Functional/V1/Auth/Join/RequestTest.php:55

Точней почему не проходят - понятно. Не понятно почему всегда 404 прилетает...

А если нам нужно добавить в регистрацию дополнительное поле, например ФИО. Оно вроде как никакого отношения к аутентификации не имеет. Т.е. мы создаем модуль "Учетная запись", для работы с профилем. И в экшене джоина обращаемся еще и к ней?