Кто-Нибудь может объяснить почему на практике интеграционные тесты называют юнит

тестами?

Например тут https://github.com/vercel/next.js/blob/canary/test/unit/image-optimizer/get-max-age.test.ts

Этот тест лежит в папке с юнит тестами. Тестируется функция getMaxAge, которая зависит от parseCacheControl. При этом parseCacheControl никак не мокается, следовательно зависимость остается, следовательно это интеграционый тест, а не юнит

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

Хорошо. Тогда еще пример: https://github.com/vercel/next.js/blob/canary/test/unit/router-add-base-path.test.ts Тестируется addBasePath, которая зависит от addPathPrefix, которая зависит от normalizePathTrailingSlash (экспортируется из другого файла) Это тоже юнит тест? У них это отнесено к юнит

а что здесь интеграционного?

внешняя зависимость от normalizePathTrailingSlash

она внутренняя. внешние — это базы данных, файловые системы, сетевые запросы...

Я теперь не понимаю как определить что внешняя зависимость, а что нет. Если я импортирую fs модуль для работы с файловой системой это внешняя зависимость?

внешней зависимостью будет файл, который тебе необходимо прочесть

Хорошо. Получается, что если у меня есть огромная библиотека, с миллионом инкапсулированных функций, которая вне отдает только одну функцию, которая вызвает весь этот миллион инкапуслированных функций, то тестирую я эту одну функцию, то я смело могу назвать свой тест юнит тестом, если нет вненшних зависимостей, о которых ты говоришь?

Юнит это не функция или метод класса. Это некая абстракция, которая инкапсулирует некую бизнес логику.

Я отталкиваюсь от этого ответа https://t.me/nodejs_ru/738819. Пока не особо понял

если ты ее мокнешь, то: * тебе придется написать интеграционный тест для работы с этой библиотекой и проверять, что поведение мока соответствует поведению библиотеки, иначе в реальном коде у тебя будет разное поведение. * для всех использований библиотеки придется писать моки и изменять их, если изменится библиотека. * и все равно ты сможешь получить ошибки в реальном коде, потому что пропустил что-то в ее интеграционном тесте. я понимаю идею "в юнит тестах всё надо мокать, чтобы у нас были стабильные зависимости". но эта идея несет в себе издержки. тесты станут хрупкими, их будет тяжелее писать, понимать, поддерживать, а багов в продакшене станет больше. на мой взгляд, гораздо практичнее использовать как можно больше реальных зависимостей.

если буквально отвечать на твой вопрос, то конечно это все еще юнит тест. он отвечает всем характеристикам юнит теста. https://www.testim.io/blog/unit-test-vs-integration-test/

Понял. Спасибо за ссылки

тема непростая. люди по-разному понимают что такое интеграционное тестирование. какого-то канона нет

Да я уже понял. В другом чате тоже задал. Каждый по-своему объясняет