user_of_toster
@user_of_toster

Примеры unit тестов реального приложения на express\koa?

Пишу тесты, моки занимают полстраницы и два часа, работа с изоляцией тестов еще полчаса, на выходе тест сомнительной пользы, в котором проверяется действительно ли один мок вызывает другой мок. Во всех найденных туториалах и книгах тестируются калькуляторы и функции sum(a, b). помогите найти примеры тестов настоящего backend приложения на express\koa. Желательно с JEST.

Только не кидайте пожалуйста тесты самого экспресса, я пишу не фреймворк.
  • Вопрос задан
  • 121 просмотр
Решения вопроса 1
search
@search
мама говорит что я особенный
Сейчас прозвучит мысль, к которой многие программисты не готовы: юнит тесты - это пустая трата времени*.

* бывают исключения, о них ниже.

Вы сами заметили что в основном тесты получаются сложнее чем код. Мок погоняет моком. А возня с тестами занимает больше времени чем работа над бизнес кодом. Это стандартная болезнь многих проектов. Причина этой болезни - вера в то что тесты каким-то чудесным образом способствуют качеству приложения. Это не так. В некоторых случаях тесты помогают быстрее писать код и быстрее его понимать. В основном это касается:
- чистых функций (типа пресловутого sum) и функций общего назначения (например из lodash)
- регулярных выражений

Юнит тесты не имеют смысла на так называем "клее". Например коде контроллера, который, в теории должен быть простым как топор. Обычно клей - это код, который связывает какие-то логические узлы, при этом сам имея тривиальную логику. Это где-то 90% кода современных приложений. Тестировать клей - так же нелепо, как и тестировать сам фреймворк или node. Тесты в стиле "сейчас мы убедимся что этот сервис вызвает другой сервис, передавая в него такие-то прараметры" обходятся крайне дорого, а на выходе не дают никакой практической ценности. Потому что тест получается сложнее чем сам клей, что противоречит постулатам TDD.

Но всё-таки хочется обладать определённой степенью уверенности в том что делаешь. Для этого есть:

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

Такие дела.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы