Модульное тестирование: нет поставщика для "InterceptableStoreFactory", даже если он добавлен в "поставщики"

Question

Я работаю над модульными тестами в своем приложении Angular, я использую подход TestBed,

Я тестирую компоненты, поэтому каждый файл спецификаций выглядит так

import...
describe('AppComponent', () => {
// Importing dependecies
    beforeEach(async(() => {
        TestBed.configureTestingModule({
            imports : [RouterTestingModule , HttpModule , FormsModule ],
            declarations: [AppComponent
            ],
            providers: [AUTH_PROVIDERS ,UserService, SharedclientService, RouteNavigator, JwtHelper, ReloadTokenService, ShopService
                , EnvVarsService, ProfileService, LocalStorageService, ApiVersionInterceptor, ApiTrackingInterceptor, MonitoringService ,
                { provide: 'LOCAL_STORAGE_SERVICE_CONFIG', useValue: userConfig } , TokenUtilService , HttpInterceptorService ,
                { provide: InterceptableStoreFactory, useClass: InterceptableStoreFactoryMock },ReloadTokenEventService , InterceptableStoreFactory

            ]

        }).compileComponents();
    }));
    // detecting changes every times
    beforeEach(() => {
        fixture = TestBed.createComponent(AppComponent);
        component = fixture.componentInstance;
        fixture.detectChanges();
    });

    // Test case 0 (compilation of the component)
    it('AppComponent is well defined', () => {
        expect(component).toBeDefined();
    });

    // Test case 1
    it('test', () => {
        expect("1").toBe("1");
    });
});

Такой подход к тестированию вызывает сбой всего набора тестов, если импорт зависимостей идет плохо.

Например: в этом тестовом наборе выдается эта ошибка:

Нет поставщика для InterceptableStoreFactory! Это кажется странным, так как я импортирую эту услугу в моих провайдеров (последний)

Это приводит почти к сбою во всех тестовых примерах, так как проверка импорта осветителей - это тесты " beforeEach "

Ищу лучшие идеи для:

1. проблема "нет поставщика услуг" (который уже добавлен к поставщикам "

и для

2. модульное тестирование - лучший способ тестирования

Answer 1

Вы предоставляете InterceptableStoreFactory дважды. Один раз с ложной заменой, один раз с оригиналом. Попробуйте удалить один из них.

Это может помочь вам создать модуль для всех ваших служб и поместить его в папку "core". (См. Угловое руководство по стилю)

Это облегчает предоставление всех необходимых услуг как в тестировании, так и в разработке / производстве, не повторяя при этом слишком много.

Answer 2

1. Нет поставщика услуг

Удалить трейлинг InterceptableStoreFactory в массиве провайдеров. Как вы уже вводите макет службы InterceptableStoreFactory раньше на той же линии.

Если это не помогло, пожалуйста, предоставьте фрагмент вашего учебного класса InterceptableStoreFactoryMock а также InterceptableStoreFactory,

2. Лучшая стратегия тестирования

Для лучшей стратегии тестирования я бы предложил несколько вещей, облегчающих тестирование:

1. Предлагаемый здесь в Angular Styleguide: собрать все глобальные услуги в один CoreModule, Вы можете легко узнать, что все сервисы импортируются, и легко импортировать их для тестирования. Я также рекомендовал бы, возможно, создание явного CoreTestingModule если вы хотите смоделировать многие из этих служб одинаково для многих компонентов. Таким образом сохраняя возможность повторного использования для всех тестов.
2. Предложенный здесь в Angular Styleguide: SharedModule в котором вы можете экспортировать компоненты, директивы и каналы, которые вы часто используете в приложении.
3. Рассмотрите возможность использования очень маленьких модулей. В часто задаваемых вопросах на одной из конференций во второй половине 2017 года или в начале 2018 года Роб Уормальд упомянул, что каждый модуль в проекте Google Angular имеет в среднем только 1,6 компонента. Это означает, что каждый тест компонента с меньшей вероятностью будет включать в себя сервисы и другие операции импорта, которые ему на самом деле не нужны. Таким образом, также требуется гораздо меньше рефакторинга тестов, если вы меняете большой модуль, используемый очень многими компонентами. С меньшими модулями ваш TestBed также будет намного быстрее, так как это происходит намного быстрее, чтобы повторно инициализировать TestBed после каждого теста.
4. Подумайте о том, чтобы перенести большую часть логики на сервисы и каналы и в первую очередь перенести на них фокус тестирования. Так как сервисы тестирования и каналы могут использовать обычную инфраструктуру тестирования и, таким образом, пропустить сложность создания модулей, поскольку сервисы и каналы могут рассматриваться как обычные классы и функции. В качестве дополнительного примечания я бы упомянул, что это более или менее выполняется автоматически путем перехода на архитектуру NGRX.
5. Эта проблема отслеживает большее улучшение производительности TestBed, Теперь проблема в том, что вам нужно заново создавать и разрывать модуль между каждым тестовым примером. Сделать это намного медленнее, чем просто тестировать сервисы, каналы и другие чистые функции и классы. Как уже упоминалось ранее, это немного исправлено с помощью меньших модулей. В этой проблеме также показано несколько способов использования Jest или обходных путей, чтобы не нужно было заново создавать модули для каждого тестового примера и использовать их повторно. Последнее, однако, меняет частные API, поэтому ваше приложение может легко сломаться между выпусками патчей Angular, что не очень удобно.