Как тесты ускоряют разработку:

– Я вообще никогда не запускаю код, который написал. Вместо того, чтобы локально разворачивать код и дергать его через Postman / Cli, мне просто достаточно написать тесты и в 90% случаев, если тесты прошли, то все будет работать.

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

Еще хуже, когда во время проверки оказывается, что ничего не работает, тогда приходится проставлять дебагинг и дергать одну и туже ручку десятки раз. С тестами это намного проще.

– Можно трогать чужой код. Рано или поздно вам придется пойти в модуль / сервис вашего коллеги и что-то там дописать. В обычной ситуации, кроме осознания написанного коллегой, вам также придется понять: "а как правильно протестировать, что я ничего не сломал?" – и времени эта проверка займет х2-3 от самой задачи.

Если же коллега написал тесты, то как минимум они должны проходить, а вы можете дополнить еще и своими кейсами.

– Бесстрашный рефакторинг. И вот это не шутки: благодаря тестам, я не боюсь взять какой-нибудь кусок, который вызывал уже много сомнений или проблем и просто ПОЛНОСТЬЮ его переписать. Почему? Потому что тесты как минимум смогут мне дать добротный кусок уверенности, что переписанный код будет также решать предыдущие задачи, но и лучше справляться с новыми.

Не знаю как вам, а для меня наличие возможности рефакторить – это очень сильный буст к уверенности в надежности проекта и удовольствия от работы с ним.

– Ну и старая добрая регрессия, а точнее, ее уменьшение. Абсолютно на всех проектах мы очень часто ловили проблему регрессии, где новый код мог затронуть старый, причем очень странным образом (обновили либу, добавили независимый плагин к существующей, добавили метод к системе логирования и т.д.), то есть, в тех местах, которые вроде было расширены, а не переписаны

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

Поэтому мой ответ такой: нет ни одного кейса, при котором наличие тестов могло бы как-либо негативно заафектить вашу производительность

Исключение только одно: вы не умеете достаточно эффективно с ними работать

Но самое прекрасное в этом исключении то, что это легко поправить, о чем я расскажу дальше

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

Я бы ещё добавил про подходы api-first vs code-first (TDD), что есть много подходов и инструментов для каждого. Опиши один раз openapi, asyncapi и получи е2е тесты в подарок, а если смотреть дальше, то mock, sdk, data model и всё остальное

api-first как раз будет в следующем посте)

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