У меня второй тест не проходит, Jasmine не понимает, что

функция была вызвана, кто знает, в чём проблема?

export const testFn = function(): void { };

export const testFn1 = function(): void {
testFn();
};

describe('Тестирование функции testFn1', () => {

beforeEach(() => {
this.moduleObj = { testFn, testFn1 };
});

it('должна выполниться без ошибок', () => {
expect(moduleObj.testFn1).not.toThrow();
});

it('должна вызывать функцию testFn', () => {
spyOn<any>(moduleObj, 'testFn');
moduleObj.testFn1();
expect(moduleObj.testFn).toHaveBeenCalled();
});

});

А this откуда?

Поправил

Всё равно не понятно, что за this

В beforeEach создаётся

Ок, а что за объект-то, на что this ссылается?

На какой-то большой объект. Я заменил на такой код, одно и тоже describe('Тестирование функции testFn1', () => { const moduleObj = { testFn, testFn1 }; it('должна выполниться без ошибок', () => { expect(moduleObj.testFn1).not.toThrow(); }); it('должна вызывать функцию testFn', () => { spyOn<any>(moduleObj, 'testFn'); moduleObj.testFn1(); expect(moduleObj.testFn).toHaveBeenCalled(); }); });

Вот ещё вариант, не понимаю, почему он не хочет слушать функцию describe('Тестирование функции testFn1', () => { let moduleObj: any = null; beforeEach(() => { moduleObj = { testFn, testFn1 }; }); it('должна выполниться без ошибок', () => { expect(moduleObj.testFn1).not.toThrow(); }); it('должна вызывать функцию testFn', () => { spyOn<any>(moduleObj, 'testFn'); moduleObj.testFn1(); expect(moduleObj.testFn).toHaveBeenCalled(); }); });

Вот так работает function testFn() {} function testFn1() { this.testFn(); } const moduleObj = { testFn, testFn1 }; describe("test", () => { it("должна вызывать функцию testFn", () => { spyOn(moduleObj, "testFn"); moduleObj.testFn1(); expect(moduleObj.testFn).toHaveBeenCalled(); }); }); Дело в том, что у вас в fn1 прямая ссылка на fn, а jasmine заменяет поле объекта на Spy и следит за ним. Но fn1 вызывает не spy, а функцию напрямую, этот вызов не отслеживается

Я привёл этот код как пример. У меня в рабочем коде есть функция, в которой 4 разных функций вызываются. Нужно проверить эти вызовы. Как это сделать, непонятно 😢

А, ты привёл рабочий код

То есть для тестирования функции, нужно её переписать?

Иногда - да

в стрикте глобального this нет же

А это не глобальный )

можно сказать что в этом и смысл тестирования

это от сборщика зависит

DI не на пустом месте придумали )

Нет, не зависит, посмотри код еще раз

А можно как-то решить не переписывая функцию? Только сервисом?

Используя DI. Не получится никак в рантайме перезаписать значение в замыкании

а ну да. вызвано в контексте

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

Вы пишите у себя юнит тесты? Вы также переписываете функции в юнит тестах, если они не используют DI? Ведь иногда какие-то функции просто выносятся в отдельные файлы, а не в класс

если вы пишите тест с испольованием контейнера — это уже интегарционный тест, а не юнит все функции, если в коде — работают внутри в классе как в черном ящике деталь

Не понимать. У меня код такой, например: function test() { test1(); test2(); test3(); test4(); } Мне нужно всегда писать так, типа?: function test() { this.test1(); this.test2(); this.test3(); this.test4(); }

То, что лежит в замыкании - часть реализации SUT, её нельзя замокать или повесить spy. Это не значит, что её нельзя протестировать. Просто вместе с тем, что в замыкании

Я не знаю слова SUT и оно не гуглится

DI - это не обязательно inject, это просто паттерн. Может быть function test(fn) {fn();}

Гуглится https://en.wikipedia.org/wiki/System_under_test Это то, что вы тестируете

Представьте, что у вас есть функция-хелпер util(), которую вы импортируете из файла и используете внутри функции foo(). В это случае util - часть реализации foo и вам не нужно её мокать или проверять, что она была вызвана. Просто тестируйте поведение foo. Вообще, смотреть на код, который вы тестируете - плохая идея, смотреть нужно на интерфейс, реализация может быть разная. Вы можете реализовать foo как с использованием util, так и без него, тест от этого не должен меняться Другое дело, если у функции есть зависимость и вызов этой зависимости - часть логики SUTа. Тогда нужно использовать DI

Ладно, не буду смотреть на возвраты функций в таком случае, просто return'ы буду смотреть

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

Зачем?

Бизнес логика приложения не должна нарушаться

Гуглится (обычно то, что гуглится находится на первых трех страницах гугла, остальное не гуглится)

Разделить функции по файлам это изменение файловой структуры Изменение бизнес-логики изменение того как функция работает

я написал ниже

Maxim Afanasev
Гуглить тоже надо уметь ) Да и зачем использовать ...

Ок, аббревиатура сама по себе не гуглится... According to ISTQB it is the test object.[