Хорошо, осталась одна проблема: как мы должны обрабатывать DI, когда мы делаем TDD?
Это действительно вызов или что? хорошо, когда мы тестируем наш фрагмент/активность, у нас может не быть доступа к нашим источникам данных, потому что они дооснащены и комната и …, у нас может быть комната в памяти, но как насчет веб-сервисов?
насколько я знаю, у нас могут быть разные подходы к решению этой проблемы:
- использование Mock Web Service для имитации сетевого подключения и прохождения надлежащей модернизации
- удалите репозиторий или UseCase DI и установите поддельный репозиторий в свой фрагмент/деятельность
Я хотел бы сделать второй подход, давайте представим, что у вас есть этот дизайн:
для теста пользовательского интерфейса мы не должны подключаться к реальному API, и нам нужно подделать одну часть нашего кода, но какая часть лучше? Я думаю, что лучший выбор - репозиторий, поэтому мы можем иметь:
но где проблема? проблема в том, что вы, вероятно, использовали DI и в этом случае Hilt, поэтому вы устанавливаете инъекцию для своего UseCase для внедрения репозитория, и если вы создаете свое приложение на правильной архитектуре, у вас должен быть интерфейс для вашего репозитория и передавать его в UseCase вместо внедрение этого репозитория (на основе принципа SOLID), и когда вы пытаетесь создать тест пользовательского интерфейса, Hilt внедрит вашу реализацию в UseCase вместо FakeRepository, вам нужно удалить этот конкретный DI и создать другой DI, но как?
давайте сначала проверим, какие библиотеки нам нужны:
хорошо, давайте посмотрим на код, и я объясню остальное:
во-первых, подумайте о том, что у нас есть модуль для предоставления вариантов использования, например:
наша проблема в том, что когда мы запускаем наш тест пользовательского интерфейса, у нас нет Интернета, и все объекты должны быть фальшивыми или издевательскими или что-то в этом роде! поэтому нам нужен правильный репозиторий, в этом случае, если вы использовали чистую архитектуру для своего проекта, у вас должен быть класс SomeRepository и класс SomeRepositoryImp, и мы не хотим SomeRepositoryImp в нашем тесте пользовательского интерфейса, вместо этого нам нужен SomeRepositoryFake! поэтому каким-то образом нам нужно переопределить SomeUseCaseModule, в нашей тестовой папке мы можем делать такие вещи, как это:
действительно просто! в этом коде, который существует в нашей тестовой папке, мы заменили наш модуль SomeUseCase его новой версией (я сделал это, но вы также можете переопределить свой RepositoryModule вместо него)
есть и другие проблемы, как видите, мы находимся в тесте, а не в фактическом коде, поэтому нам нужно изменить наш граф зависимостей, нам нужна другая активность и другое приложение, и нам не нужна наша фактическая активность или приложение.
поэтому на самом первом шаге нам нужна другая активность, вы можете поместить ее в свою папку отладки или тестовую папку (я видел, что большинство людей создают папку отладки рядом с основной и тестовой папками и помещают туда этот код):
и вам также нужен манифест для этой деятельности, например:
теперь подумайте о том, что мы хотим протестировать фрагмент, в библиотеке тестирования Android у вас может быть что-то с именем Scenario, вы можете запустить сценарий действия или сценарий фрагмента, но этот подход не будет работать с рукоятью, нам нужно настроить это, поэтому у нас может быть такое расширение:
этот код запустит сценарий HiltAndroidActivityTest и прикрепит к нему фрагмент, это общий код, который вы можете найти в каждой статье!
Осталось другое, и это изменение вашего реального класса приложения с помощью HiltTestApplication, который предоставляется библиотекой hilt, давайте посмотрим на тест пользовательского интерфейса:
здесь я использовал Robolectric, библиотеку для тестирования пользовательского интерфейса, преимущество этой библиотеки заключается в следующем: вы можете поместить свой тест пользовательского интерфейса в тестовую папку вместо androidTest, поэтому вам больше не понадобится устройство или эмулятор, как вы можете видеть I поместите некоторую конфигурацию, например версию SDK и т. д., но важно то, что это приложение, я передал тип HiltTestApplication, поэтому тест сгенерирует другой граф зависимостей, вам также необходимо добавить HiltAndroidRule в качестве правила, чтобы Hilt мог предоставить ваши зависимости в тесте .
и теперь вы можете протестировать свой фрагмент и быть счастливым :)
любая проблема => свяжитесь со мной: [email protected]
