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

Question

[user_of_toster]

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

Только не кидайте пожалуйста тесты самого экспресса, я пишу не фреймворк.

Comments

[WbICHA]

моки занимают полстраницы

Ты в них что, весь функционал переписываешь подробно?

[user_of_toster]

WbICHA, нет, просто есть 4-5 зависимостей. Каждая зависимость берет в качестве аргумента объект, который нужно описывать. Описание объекта занимает по 3-5 строк.

[WbICHA]

user_of_toster, а зачем тебе описывать объект в моке?

[user_of_toster]

WbICHA, описывается возвращаемое моком значение

[WbICHA]

user_of_toster, скинь код.

Answer 1

[Demian Smith]

Сейчас прозвучит мысль, к которой многие программисты не готовы: юнит тесты - это пустая трата времени*.

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

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

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

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

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

Такие дела.

Comments

[user_of_toster]

Теперь следующая проблема - доказать тимлиду, что юнит-тесты не нужны)

[Demian Smith]

Это очень непросто сделать. Люди часто смотрят на тесты с религиозным благоговением. Объяснить членам команды что тестировать клей глупо и бесполезно зачастую так же сложно как объяснить, например, конспирологу что земля не плоская. В какой-то момент он откатывается до "я тебе не верю" и диалог невозможно продолжать.

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

1. Зарекомендовать себя как инженер, который что-то из себя представляет
2. Ненавязчиво намекать на то что тесты клея ничего не дают на конкретных примерах

В своё время (где-то 5 лет назад) мой коллега переконвертировал меня из "мистера 100% покрытие" в мистера "может не будем трахать себе мозги?". Когда он начал диалог о вредности тестов клея, я думал что чувак сошел с ума.

Года 3-4 назад я проделал такой же трюк со своей командой. После того как убедился что команда мне доверяет, я начал потихоньку избавляться от глупых тестов. Ребята тоже думали что я спятил и проект укатится в ад. Моим главным аргументом был тот факт что на проекте, за который я отвечал (делал лично и деплоил раз в две недели) было очень мало тестов и в течении года не было выявлено ни одного продакшн бага. С этим фактом было невозможно поспорить. Короч, в итоге всем очень понравилось не парить себе мозги ))

На текущем проекте мне понадобилось месяцев 5-7 чтоб достучаться до коллег.

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

[Demian Smith]

Причём прикол в том что ребят "а давайте всё покроим тестами" больше чем хотелось бы. Их можно встретить где угодно. В своё время я был таким и к своему стыду, работая во внутренней команде Апворка (тогда Одеска) убедил руководство в том что тестов мало не бывает. Я сейчас представляю как фыркали ребята поопытнее. Лучший друг (и по совместительству сосед) сейчас работает в одной из команд AWS в Амазоне и тоже жалуется на таких товарищей. Так что уходить в другую компанию в надежде что там не будет этого бреда - не вариант.

[user_of_toster]

Demian Smith, а какими аргументами вы в основном пользуетесь для переубеждения коллег? На "тесты функции сложнее самой функции" можно получить "значит, не умеешь писать тесты\ пишешь их неправильно" или "цена ошибки будет больше, чем цена написания этого теста"

[user_of_toster]

Demian Smith,

Моим главным аргументом был тот факт что на проекте, за который я отвечал (делал лично и деплоил раз в две недели) было очень мало тестов и в течении года не было выявлено ни одного продакшн бага.

Похоже, путь от 100% покрытия до частичного обязателен для того, чтобы иметь примеры проектов, с помощью которых можно переубедить коллег)

[Demian Smith]

Эти дискуссии ни к чему не приводят. Серьёзно. Это вопрос веры. Тут не место спорам. Это будет как спор с антиваксером. Просто тупой спор. Нужно потихоньку склонять людей задуматься. Например

- каждый раз когда возникает баг/ошибка, восклицать "это невозможно! у нас ведь там ЮНИТ ТЕСТЫ, ТАМ НЕ МОЖЕТ БЫТЬ ОШИБОК!!!!"
- просить помочь когда самому лень этим заниматься
- внимательно следить за происходящим и обращать внимание людей на эту проблему "вам не не кажется что мы сейчас хернёй занимаемся?"

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

Это не быстрый процесс. Тут помогает авторитет. Прийдётся быть безупречным во всём что делаешь. Потому что к говноляпам не особо прислушиваются. Даже если они дело говорят иногда.