@MrOnlineCoder

Добрый день. Есть уже достаточно большое приложение на Node.js (Express), и к сожалению, в нем отсутствуют тесты. Хотел спросить совета и уточнения по этому делу:

1. Правильно ли я понимаю, что есть юнит тесты, которые тестируют какую-то очень маленькую часть приложения (например функцию или класс), и есть интеграционные тесты, которые тестируют сам HTTP API?

2. Для старта достаточно ли будет интеграционных тестов? Кодовая база достаточно большая уже, и покрыть ее всеми видами тестов за отведенный срок не получится. А интеграционные тесты вроде есть какой-то "золотой серединой" (дольшее время выполнения по сравнению с юнит тестами не критично)

3. Насколько я понимаю, при проведении юнит тестов зависимости модуля, который тестируются, "мокаются" и используются заглушки (т.е. вместо реальной записи в бд, функция-заглушка просто притворяется что сделала запись и возвращает результат). Однако, как тестировать это когда зависимости в приложении подключаются через обычный require()? Неужели все такие хорошие программисты, что с самого начала в проекте продумывают так архитектуру и используют Dependency Injection со всякими интерфейсами?

4. Какие инструменты выбрать для тестов? я пока остановился на jest + supertest.

5. Каике есть гайды или best-practice о том, как правильно писать интеграционные тесты? Знаю про прницип Arrange-Act-Assert, и про использовнии названий тестов из трех слов, но как именно тестировать более менее сложные API - нет. Как быть с авторизацией, когда нужно запрос требует чтобы пользователь был авторизирован?

Заранее спасибо за любую помощь.

0

@muxahuk1214

по сути да. Ниже занятная статья на этот счёт.
https://www.softwaretestinghel... l-testing/

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

Если нет ничего, то и это сойдёт.. тут же всё зависит от ситуации, в идеальном мире конечно нужно/можно делать и те и те тесты параллельно и покрыть 100% кода, но есть реалии и на что хватает то и делаем, что считаем лучше. Если важна часть интеграционная (что бы клиент получал данные с определёнными параметрами), то лучше начать с интеграционных тестов, если не столь важна эта часть, а то что бы убедиться что на уровне юнитов всё работает стабильно - лучше юнит тесты.
Я бы выбрал самые изменяющиеся части кода и покрыл бы их юнит тестами, а всё остальное - интеграционными

хочется надеяться что самые светлые из нас так делают.. но как правило нет и для этих случаев есть специальные плагины, которые в тестах могут подменить require (твоего когда) на мокнутую версию
https://www.npmjs.com/package/mock-require - как пример, но если поискать можно найти более "продвинутые" варианты, которые более гибкие..
Так же можно просто по вебу полазить поискать как люди мокают базы данных, так как для этого тоже есть разные варианты, когда мокается сам клиент и он вроде как продолжает работать, но не делая реальных запросов в базу (ух давно я этой фигнёй не занимался..)
И кстати, есть такой уровень тестирования, он скорее относиться к интеграционному тестированию, это когда ты подключаешь базу для тестирования и прогоняешь свой код с тест базой, но при этом на уровне кода, а не клиента..
ну т.е. проверяешь что интеграция между сервисом и базой работает правильно, а не между хттп сервером, сервисом и базой..

я лично предпочитаю моку, но разницы нет..
добавить сюда ещё мок библиотеку (типо синон [https://www.npmjs.com/package/sinon], хотя может это уже встроено в jest?) + библу для мока require [ссылка выше или подобный] + если искать специальный мок для "драйвера" базы то и его можно..

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

ЗЫ: есть ещё такой паттерн как нанять тестировщика и что бы он написал тесты на каком нибудь селениуме за тебя и вину на него сваливать если чо.. а там уже пусть он разбирается какие паттерны использовать)))

ЗЫЫ: тесты, если их писать "правильно" займут где-то 2/3 всего времени проекта, по этому стоит выбрать конкретные вещи "которые должны работать стабильно" и делать фокус на них

2

@MrOnlineCoder

muxahuk1214, большое спасибо за развернутый ответ! Опишу ситуацию, есть проект, и хорошо было бы к нему тесты написать, однак времени мало, тестировщика нанимать тоже пока возможности нет. Весь проект работает по обычному HTTP API. Достаточно будет отправлять самые используемые запросы и проверить хттп ответ? Базу мокать не знаю нужно ли, да и как, к сожалению там все на обычных реквайрах, и хз как замокать нормально такое.

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

0

@muxahuk1214

да, можно начать с этого и по оставшемуся времени добавлять и другие сценарии тестов...

0