Тестирование поведения классов с глубокими вложенными зависимостями
Я начал использовать Behat, и я думал, как правильно сделать что-то вроде этого:
Я тестирую поведение системы с помощью Behat (домен, а не веб) и хочу протестировать поведение, которое использует класс UserService. UserService принимает UserRepository (Interface) в качестве аргумента. Должен ли я создать объект UserService в контексте или я должен взять его из некоторого контейнера внедрения зависимостей (которого у меня сейчас нет, так как я хочу сначала смоделировать домен)? Или я должен создать фабрику для создания UserService? Должен ли я издеваться над этими зависимостями?
Проблема здесь в том, что может быть несколько реализаций UserRepository, и я хочу протестировать ту, которую использует система (следовательно, беря UserService из контейнера DI). Я не знаю, какую реализацию я собираюсь использовать во время написания файла / контекста. Вероятно, просто фиктивный FilesystemUserRepository просто для прохождения тестов.
Если бы я использовал FilesystemUserRepository в контекстах, то после того, как я решил перейти к DatabaseUserRepository позже в разработке, мне пришлось бы переписать все контексты, которые используют класс UserService.
Есть ли лучшая практика, как это сделать?
Решение
Я обычно начинаю с создания всего в конструкторе моего контекста, так как на этом этапе я много двигаюсь вперед и назад, и я не хочу отвлекаться на необходимость создания определений сервисов. На этом этапе код может сильно измениться, так что в любом случае он будет довольно неэффективным.
Позже я создаю определения сервисов в контейнере приложения. С контейнером Symfony очень легко внедрить эти услуги непосредственно в ваш контекст. Другое преимущество заключается в том, что в средах Symfony вы можете заменить некоторые службы в тестовой среде. Я на самом деле часто использую это, так как я предпочитаю использовать репозитории в памяти в приемочных тестах, а не те, которые основаны на базе данных.
В некоторых проектах я не сделал второго шага и оставил инициализацию сервиса в классе контекста Behat. Это тоже хорошо сработало.
Другие решения
Других решений пока нет …