[Перевод] Меняем моки репозиториев на in-memory реализации09.02.2024 18:30

Реализация, выполняющая эти тесты, использует простой массив, содержащий объекты, которому нужно только проверить, содержит ли массив уже переданный Item, чтобы не вставлять его несколько раз:

items)) {
            return;
        }
        $this->items[] = $item;
    }

    public function loadAll(): array
    {
        return $this->items;
    }
    public function loadFilteredByTitle(string $titleFilter): array
    {
        return array_values(
            array_filter(
                $this->items,
                fn (Item $item) => str_contains($item->getTitle(), $titleFilter),
            ),
        );
    }
}

Единственное, что здесь немного громоздко, — это метод loadFilteredByTitle, поскольку этот метод будет реализован только для тестов, что было бы не нужно, если бы использовались моки. Но, следовательно, моки могут привести к неправильным результатам тестирования, если поведение этого метода по какой-то причине изменится. В данном примере был использован array_filter для возврата элементов, соответствующих заданным критериям, но также можно использовать цикл foreach или что-то другое, что подходит именно вам. Конечно, это все еще очень простой пример, и в зависимости от реальной логики его может быть сложнее реализовать, но я не считаю это напрасным трудом, поскольку это дает мне уверенность и быстрые тесты.

Эта реализация не может быть использована в продакшене, если только вы не хотите, чтобы каждый запрос изначально не содержал никаких данных. Однако в остальном эта реализация ведет себя точно так же, как и Doctrine-реализация, которая фактически сохраняет данные в базе данных. Это делает ее отличным кандидатом для использования в других тестах, многие из которых, вероятно, использовали бы моки.

Используем правильную реализацию в каждой среде

Теперь, когда у нас есть две реализации одного и того же интерфейса, мы можем выбирать, какую из них использовать, например, в REST-контроллере, как показано в следующем коде:

query->getString('titleFilter');
        $items = $titleFilter ? $itemRepository->loadFilteredByTitle($titleFilter) : $itemRepository->loadAll();
        return $this->json($items);
    }

    #[Route('/items', methods: ['POST'])]
    public function create(Request $request, ItemRepositoryInterface $itemRepository): JsonResponse
    {
        /** @var \stdClass */
        $data = json_decode($request->getContent());
        $item = new Item($data->title, $data->description);
        $itemRepository->add($item);
        return $this->json($item);
    }
}

Это довольно стандартный контроллер Symfony, использующий интерфейс ItemRepositoryInterface для внедрения одной из вышеупомянутых реализаций. В наши дни Symfony поставляется с автоматическим разрешением зависимостей (autowiring), так что обычно не нужно ничего настраивать. Однако, поскольку у нас есть две реализации интерфейса ItemRepositoryInterface, Symfony сама по себе не может знать, какую из них использовать. Поэтому мы должны добавить следующую строку в файл config/services.yaml:

services:
    # other stuff...
    App\Domain\ItemRepositoryInterface: '@App\Repository\Doctrine\ItemRepository'

Таким образом, Symfony будет знать, что он должен внедрить ItemRepository Doctrine каждый раз, когда используется ItemRepositoryInterface.

Обратите внимание, что контроллер не вызывает метод EntityManagerInterface::flush. Я предпочитаю избегать использования таких методов в контроллере, так как в зависимости от того, какой ItemRepositoryInterface используется, это может и не понадобиться. Однако в случае с Doctrine-реализацией это все-таки необходимо делать, поэтому я сделал для этого слушатель:

 ['flush'],
        ];
    }

    public function flush(): void
    {
        $this->entityManager->flush();
    }
}

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

Тест для этого контроллера можно реализовать примерно так:

getContainer()->get(ItemRepositoryInterface::class);
        $itemRepository->add(new Item('Title 1', 'Description 1'));
        $itemRepository->add(new Item('Title 2', 'Description 2'));

        $client->request('GET', '/items');
        $responseContent = $client->getResponse()->getContent();
        $this->assertNotFalse($responseContent);

        $responseData = json_decode($responseContent);
        $this->assertIsArray($responseData);
        $this->assertCount(2, $responseData);
        $this->assertEquals('Title 1', $responseData[0]->title);
        $this->assertEquals('Description 1', $responseData[0]->description);
        $this->assertEquals('Title 2', $responseData[1]->title);
        $this->assertEquals('Description 2', $responseData[1]->description);
    }
    public function testListWithTitleFilter(): void
    {
        $client = static::createClient();

        /** @var ItemRepositoryInterface */
        $itemRepository = $client->getContainer()->get(ItemRepositoryInterface::class);
        $itemRepository->add(new Item('Test title 1', 'Description 1'));
        $itemRepository->add(new Item('Title 2', 'Description 2'));
        $itemRepository->add(new Item('Test title 3', 'Description 3'));

        $client->request('GET', '/items?titleFilter=Test title');
        $responseContent = $client->getResponse()->getContent();
        $this->assertNotFalse($responseContent);

        $responseData = json_decode($responseContent);
        $this->assertIsArray($responseData);
        $this->assertCount(2, $responseData);
        $this->assertEquals('Test title 1', $responseData[0]->title);
        $this->assertEquals('Description 1', $responseData[0]->description);
        $this->assertEquals('Test title 3', $responseData[1]->title);
        $this->assertEquals('Description 3', $responseData[1]->description);
    }
    public function testCreate(): void
    {
        $client = static::createClient();

        /** @var ItemRepositoryInterface */
        $itemRepository = $client->getContainer()->get(ItemRepositoryInterface::class);

        $client->jsonRequest('POST', '/items', ['title' => 'Title', 'description' => 'Description']);

        $items = $itemRepository->loadAll();
        $this->assertCount(1, $items);
        $this->assertEquals('Title', $items[0]->getTitle());
        $this->assertEquals('Description', $items[0]->getDescription());
    }
}

Я не буду вдаваться во все подробности тестирования в Symfony (документация по тестированию Symfony и так проделала приличную работу в этом направлении), вместо этого я расскажу только об основных моментах: Этот тест использует интерфейс ItemRepositoryInterface вместо интерфейса Doctrine. Он используется для установки некоторых данных в тестах testList и testListWithTitleFilter, а также для подтверждения того, что данные действительно были сохранены testCreate. Если запускать тесты в таком виде, они не часто будут успешными, поскольку база данных не сбрасывается. Однако цель этой статьи не использовать базы данных для такого рода тестов. Поэтому вместо этого создается файл config/services_test.yaml, который содержит следующие строки:

services:
    App\Domain\ItemRepositoryInterface: '@App\Repository\Memory\ItemRepository'

Таким образом, для всех тестов ItemRepository использует только массив, всякий раз, когда происходит обращение к интерфейсу ItemRepositoryInterface, будет задействоваться in-memory реализация. Это означает, что при такой конфигурации в приведенном выше тесте для контроллера вообще не используется база данных, что делает тесты невероятно быстрыми. В то же время эти тесты вполне надежны, поскольку in-memory реализация ведет себя как Doctrine-реализация благодаря AbstractItemRepositoryTest.

Единственный тест, реально работающий с базой данных, — это ItemRepositoryTest для Doctrine-реализации, который внедряет только интерфейс EntityManagerInterface, поэтому конфигурация в services_test.yaml в данном случае не будет применяться.

Заключение

Подводя итог, могу сказать, что я никогда не был так доволен своими тестами. Они невероятно быстры, вселяют уверенность результаты, поскольку in-memory реализация должна вести себя очень похоже на Doctrine-реализацию, и нет необходимости переопределять множество ожиданий во многих тестах, как это было бы в случае с моками.

Единственный минус, который я могу придумать, — это то, что в случае с хранилищами данных сложные запросы может быть трудно реализовать, используя только массив, но, на мой взгляд, это не является серьезным препятствием. И довольно часто некоторые вызовы методов массивов, таких как array_filter, уже сильно помогают в этом вопросе.

Я очень рекомендую вам попробовать этот вид тестирования в ваших проектах, и я уверен, что вы об этом не пожалеете!

Статья подготовлена в преддверии старта курса OTUS «Symfony Framework».

© Habrahabr.ru