Как имитировать импорт файлов среды в модульные тесты

В нашем угловом приложении мы используем файлы окружения для загрузки некоторой конфигурации.

environment.ts

export const environment = {
  production: false,
  defaultLocale: 'en_US',
};

Затем мы используем его в одном из наших сервисов:

import { environment } from '../../environments/environment';
import { TranslateService } from './translate.service';

@Injectable()
export class LocaleService {
  constructor(private translateService: TranslateService){}

  useDefaultLocaleAsLang(): void {
    const defaultLocale = environment.defaultLocale;
    this.translateService.setUsedLang(defaultLocale);
  }
}

Поэтому я использую значения в файле среды в методе службы.

В нашем тестовом файле мы можем, конечно, Spy на translateService:

translateService = jasmine.createSpyObj('translateService', ['setUsedLang']);

Но я не знаю, как издеваться над значениями среды в моем тестовом файле (например, в beforeEach). Или даже преобразовать его, для целей тестирования, в Subject чтобы я мог ее изменить и протестировать по-разному.

В более общем плане, как вы можете издеваться над такими значениями импорта в тестах, чтобы не использовать реальные значения?

Ответ 1

Вы не можете тестировать /mock environment.ts. Он не является частью системы Angular DI, это жесткая зависимость от файла в файловой системе. Процесс угловой компиляции - это то, что позволяет заменять различные environment.*.ts файлы под капотом, когда вы делаете сборку.

Угловая система DI - это типичный объектно-ориентированный подход, позволяющий сделать части вашего приложения более надежными и настраиваемыми.

Моя рекомендация заключалась в том, чтобы воспользоваться системой DI и использовать что-то вроде этого экономно

import { environment } from '../../environments/environment';

Вместо этого сделайте то, что Угловая делает для этих зависимостей, от которых вы хотите отвлечь вас от нее. Сделайте сервис, который обеспечивает шов между данными environment.ts и вашими частями приложения.

Он не должен иметь никакой логики, он мог бы просто напрямую передать свойства environment (поэтому он не нуждался бы в проверке).

Затем в ваших сервисах/компонентах, которые зависят от environment.ts Во время выполнения вы можете использовать эту услугу, и во время тестирования вы можете издеваться над ней, используя данные из другого места, кроме environment.ts

Ответ 2

Техника, которую я использую в подобных ситуациях, заключается в создании службы оболочки, например EnvironmentService.ts и в этом случае возвращает конфигурацию среды.

Это позволяет мне имитировать вызовы метода EnvironmentService getEnvironmentConfiguration, как и любой другой вызов spyOn.

Это позволяет модифицировать переменные среды в модульных тестах :)