Менеджер не виноват в том, что код не покрыт тестами.

Тесты — это хорошо. Тесты нужны. Но почему-то их не всегда пишут. Почему так происходит?

В разработке важно соблюсти баланс между скоростью и качеством. Тестирование, на мой взгляд, стоит рассматривать как инструмент, помогающий улучшить эти показатели. И качество, и скорость. Обычно про тесты вспоминают, когда что-то сломалось, да ещё и непонятно, где именно, нужно дебажить. Тогда разработчик говорит: «А вот были бы у нас тесты, мы бы сразу этот баг поймали. Теперь придётся какое-то время искать, что не работает и придумывать, как это исправить. Ну разве я виноват? Времени нам на тесты не дают. И задачи написать тесты никогда не ставили. Только новый функционал требуют. А потом удивляются, почему всё постоянно падает и мы медленно разрабатываем». Я сам так много раз делал.

Но если мы рассматриваем тестирование как инструмент, разве менеджер должен говорить, какими инструментами пользоваться, а какими — нет? Разработчику ведь не нужно ставить задачу установить себе среду разработки, вместо того, чтобы писать в блокноте, или создать Git-репозиторий. Может быть отчасти в этом есть вина микроменеджеров, которые пытаются максимально контролировать всё, что делает разработчик. Но только отчасти. На менеджмент надежды в этом вопросе точно нет. Они вообще в этом не разбираются и не должны. Отсутствие тестов объясняется либо тем, что это на самом деле плохой инструмент, который совсем не помогает, либо тем, что мы, разработчики не умеем пользоваться этим инструментом. Я больше склоняюсь ко второму. Тогда единственная причина отсутствия тестов - это просто неумение их использовать.

Для себя я выявил пока только 1 сценарий использования тестов, когда они мне действительно помогают. Это рефакторинг большого куска сложной логики. Именно рефакторинг, то есть в конце должен быть такой же результат, как и в начале. Я создаю тесты на основе старого кода. Затем переписываю код и тесты обычно находят что-то, что я пропустил. Без тестов это было бы невозможно. Тестирование — не такой простой инструмент. Нужно учиться им пользоваться.

update 2026
Добавлю оговорку, что написанное выше справедливо, если оценка перфоманса разработчика в компании вообще зависит от того насколько качественный код он пишет. Это не всегда так. Можно себе представить тимлида, который будет смотреть пр-ы и говорить, “зачем ты тратишь время на тесты, лучше бы следующую задачу взял”. А код в большинстве команд общий, если только 1 будет пытаться использовать тесты, то, я думаю, польза проекту будет всё равно. Но вряд ли это свяжут с конкретным разработчиком. В тесты будет вкладывать время 1 разработчик. А бенефиты от них распределяются между всеми.

Ещё я заметил, что даже при решении алгоритмических задач иногда тесты полезны. А там цикл поддержки кода максимум 2 часа. Бывает такое, что написал какой-то большой кусок кода из нескольких функций, прогоняешь тестовые примеры - какие-то из них дают не правильный ответ. Исправляешь что-то, и ломаются другие примеры. Быстрее написать автотесты, чтобы быстро понимать что сломалось. Да и когда нужно найти в коде баг, вместо дебага, иногда быстрее будет написать тесты на какие-то части логики, тем самым сузив область поиска.