Шаблон Внедрение зависимости (DI) является подмножеством Инверсии управления и является полезным методом для отделения создания зависимости от самого объекта. Но пусть вас не пугает терминология! DI на самом деле просто дает объекту его переменные экземпляра.
Например, ниже представлен простой пример класса Player, неявно связанного с классом Bag. Проигрыватель отвечает за создание зависимых объектов:
Хотя пример прост, довольно легко увидеть, что эту реализацию может быть сложно протестировать изолированно, поскольку теперь вам нужно знать о классе Bag в классе Player. ' тестовое задание. Д. Я могу помочь нам здесь:
Во втором примере мы «инвертировали управление» инвентарем игрока, и теперь мы передаем экземпляр объекта хранилища во время выполнения. Это означает, что в нашем тесте мы можем просто заглушить объект инвентаря:
Классу Player больше не нужно ничего знать о сумке, а также он позволяет использовать другие типы классов объектов хранения. Большой!
Внедрение зависимостей компонентов
Недавно я понял, что шаблон DI также может быть использован с большим эффектом в компонентах Ember. Например, предположим, что у вас есть контейнер или родительский компонент, который использует несколько дочерних компонентов:
Основная обязанность родительского компонента edit-location - предоставить пользовательский интерфейс для редактирования местоположения. На нем могут быть определены действия, например:
Компонент google-map предоставляет пользовательский интерфейс, позволяющий пользователю поставить маркер на карту и настроить радиус вокруг маркера с помощью элемента управления радиусом. Излишне говорить, что взаимодействие с пользовательским интерфейсом довольно сложно протестировать, и оно проверяется в тесте самого компонента google-map. Поскольку компонент edit-location тесно связан со своими дочерними компонентами, его тестирование - непростая задача. Нам нужно убедиться, что все дочерние компоненты настроены правильно, что вводит множество шаблонов в нашем тесте интеграции компонентов.
Не моя забота
В этом случае самому компоненту edit-location не нужно беспокоиться о том, как latLng и radius аргументы передаются в его действия. Пользовательский интерфейс перетаскивания - это проблема компонента google-map, и поэтому его следует протестировать в собственном тесте интеграции компонентов.
Используя DI, мы можем отделить компонент edit-location от его дочерних компонентов и очистить наши тесты. Этот метод в настоящее время возможен только с контекстными компонентами из-за использования помощников component и hash, которые были доступны в Ember 2.3.0.
Мы передали хэш дочерних компонентов с помощью помощников hash и component. Это фактически инвертирует управление в шаблон, который вызывает форму edit-location:
Установите тестовый помощник здесь:
ember install ember-test-component
Теперь в наших тестах нам нужно будет написать небольшой помощник по тестированию (или использовать надстройку выше), чтобы создать фиктивный компонент, который мы можем использовать для бездействия (ничего не делать). Благодарим @runspired за то, что он подтолкнул меня в правильном направлении:
Этот помощник по тестированию регистрирует поддельный компонент в контейнере, что делает его доступным для использования в нашем тесте интеграции компонентов:
Теперь мы можем протестировать сам компонент edit-location, не беспокоясь о настройке дочерних компонентов. Тем не менее, DI по-прежнему позволяет нам тестировать эти дочерние компоненты, интегрирующиеся с edit-location, в более контролируемой среде:
Надеюсь, вы найдете это полезным! Это ни в коем случае не панацея, но DI может помочь вам лучше писать изолированные компоненты и упростить ваши тесты.
До скорого! 👋
