Как в тестах Jasmine внутри тестируемого метода подменить значение переменной на другое?

Question

[sanex3339]

Проблема - тестирую метод, в котором значение одной переменной равно свойству статического класса (es6),
при том, что сами Settings.urlParams создаются после вызова статического метода init() класса Settings, метод init() вызывается вообще в совершенно другом месте.

.....
let urlparams = Settings.urlParams;
.....

Сейчас при тесте если импортировать в spec с тестом помимо тестируемого класса еще и класс Settings, в beforeEach вызвать Settings.init(), то во время теста метода - тест проходит.

Как мне сделать фейковый класс Settings, что бы в тестируемом методе значение переменной обращалось бралось из свойства фекового класса?

Пробовал создать внутри файла с тестом класс Settings, с этим свойством, устанавливаемым в методе init(). В beforeEach теста вызываю Settings.init(), но в тесте значение переменной не видит мой фейковый класс, хотя если сделать console.log в beforeEach, то данные отобразятся фейкового класса, что логично.

Answer 1

[Константин Китманов]

метод init() вызывается вообще в совершенно другом месте

Тестами можно покрыть только то, что имеет явное и воспроизводимое состояние.

Как мне сделать фейковый класс Settings, что бы в тестируемом методе значение переменной обращалось бралось из свойства фекового класса?

Никак. В момент объявления функции, которая использует Settings, происходит замыкание, и в функции сохраняется ссылка именно на то значение внешней переменной Settings, которое было на момент объявления. Это можно обойти, но я вам не скажу, как, а то вы такого наворотите, что мама дорогая:)

Но вообще какая-то странная у вас архитектура. Класс, у которого есть статический метод init — это очень странно пахнет. Синглтон, что ли? Если да, то бросьте бяку.

Comments

[sanex3339]

Settings - класс, что-то типа глобального объекта со всеми общими значениями (которые могут быть перезаписаны), используемыми в разных классах. Не синглтон. Статичный, что бы не вызывать во всех других классах, где он используется его через new Settings, а просто при любой надобности использовать var myVariable = Settings.sizes.width, к примеру.

[sanex3339]

Settings.init() - практически 1-е, что происходит при работе скрипта, затем уже создаются объекты других классов и т.п. Разумеется, значения, уникальные для каждого экземпляра других объектов хранятся в самих экземплярах, а не в Settings.

[Константин Китманов]

sanex3339: то есть у вас все завязано на этот глобальный объект Settings? Такое трудно покрывать тестами. По хорошему надо переписать так, чтобы все зависимости были максимально явными. В качестве полумеры можно предложить мокать этот Settings через global.Settings = MyFakeSettings (или window.Settings = MyFakeSettings — смотря где у вас тесты проходят).

[sanex3339]

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

[Константин Китманов]

sanex3339: мне лень придумывать пример. Покажите, что у вас есть, я поправлю.

[sanex3339]

beforeEach(() => {
window.Settings = {
urlParams: {параметры}
};


console.log(window.Settings.urlParams);
});

it('должен корректно получаться объект с названиями параметров и их значениями', () => {
result = UrlManager.getUrlParameters();
expect(result).toEqual(expected);
});

Ну и надо что бы window.Settings.urlParams подставился переменной urlparams , заместо = свойства класса Settings.urlParams

[Константин Китманов]

sanex3339: ну вообще должно работать, если этот тест в браузере запускается.

[sanex3339]

phantomJS, не, не работает. Неужели нет нормальных способов? Куча же ситуаций, когда внутри методов у которых нет аргументов - используются зависимости: вызываются другие классы, создаются объекты классов и вызываются методы этих объектов (не важно - статические методы или нет), которые надо для тестов сделать фейковыми, только в моем случае не метод а свойство.

[Константин Китманов]

sanex3339: хм, а как UrlManager получает ссылку на Settings?

Нормальный способ, как я уже говорил, это переписать. Глобальные зависимости, синглтоны, вот это все — ведет к нетестируемому коду. Зависимости должны быть явными и передаваться тоже явно. Это особенно нужно для тестов, ну и для уменьшения связанности тоже.