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

Ну я не стану врать, что мои юнит-тесты постоянно находят ошибки, которые иначе никак не заметить, и которые уходят в продакшен. Повторюсь, пост основан на моем опыте. Я не утверждаю, что это все верно и для вашего.

А в моем же случае написать юнит-тест на новый кусок кода не занимает больше 10-15 минут. В моем личном опыте написание тестов более чем оправдано. Иногда бывает, что добавление функциональности в одном месте ведет к ошибкам в другом, и тесты ловят такой регресс.

Я с вами согласен насчет специфики. Правильнее даже сказать, что пост написан исходя из моего личного опыта, в котором наличие тестов упрощало жизнь.

> Но да, нужно уметь читать код, а не только названия функций.

Хочу только добавить, что чтобы уметь читать код, нужно прежде всего уметь его писать :)

Никто и не говорит про обмазывание тестами.

> Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?

Я не знаю специфику вашей работы, но в моем опыте написать юнит тест – это лишние 10 минут. А отправка кода в тестирование, возвращение на доработку, анализ логов и повторный вход в контекст – побольше.

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

Я тоже не спорю, что в каждой ситуации нужно принимать грамотное решение и не следовать слепо утверждениям.

Пост я писал из своего опыта – а это энтерпрайз с более-менее крупными модулями. Тут с тестами однозначно лучше, чем без них.

> У меня было много задач, которые состояли почти целиком из интеграции разных систем. Тесты в таком случае получаются почти полностью состоящими из моков и т.п., и ну вот нифига никакие баги реальные не ловят.

Вот это кстати очень хорошо объясняет мне вашу позицию. Я согласен, что тестировать моки не имеет смысла. В моем же опыте сами модули довольно крупные, и в них юнит-тесты вписываются замечательно с минимумом моков.

> Отрефакторили. Бац — а все уже совсем хорошо.

А бывает, что отрефакторили – и что-то не то. Тесты такое отловят :)

На самом деле, я думаю, что мы говорим об одном и том же, но с разных ракурсов.

Вы хотите сказать, что тесты – это не самоцель, и важен баланс, или в принципе против тестов?

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

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

> Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.

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

> Я могу поверить что часть юнит-тестов можно заменить хорошим языком программирования. Но я не понимаю чем можно заменить интеграционные тесты.

А я не могу. Языкам программирования нет дела до бизнес-логики приложения, а тестируют именно ее, а не базовые конструкции языка.

> выбрать язык с более строгой статической системой типов, который не даст написать некоторые вещи неправильно

Поверьте, это не особо поможет) Статическая система типов не беспокоится о вашей бизнес-логике.

Насчет дороговизны отсутствия тестов – нет, не измерял, вот честно. Но мне лично это кажется очевидным.

Кейс:
1. Разработчик пишет код без тестов. Запускает локально проект, вроде норм. Отдает тестировщикам
2. Тестировщики находят баги, возвращают
3. Разработчик продолжает ковыряться и получать зарплату

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

Это все условно, конечно. Ситуации в вакууме. Я согласен, что есть грань, и нужно преследовать не какие-то конкретные цифры в покрытии, а просто делать хорошо.

Я бы сказал, что основная цель любого занятия – сделать хорошо. Сделать так, чтобы результатом твоей работы могли пользоваться другие и получать от этого пользу. Это и есть качественно выполненная работа. Тесты помогают этого достичь, не более. Их может быть больше или меньше, просто надо всегда здраво оценивать ситуацию и работать не результат.

Забыл добавить – когда проект сложно поднимается локально, то юнит и интеграционные тесты помогают понять, написали ли вы что-то рабочее или же нет.

Вы описали идеальную картину мира, как по мне. Но на деле это, как и любые другие идеалы, недостижимо.

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

Разумеется, ни пользователь, ни заказчик не скажут вам про важность тестов. Это не их компетенция, им просто нужен работоспособный продукт. А его работоспособность обеспечивают не только хорошие специалисты, но и хорошее тестирование (как QA, так и модульное).

Спасибо за дополнение!

Вы слишком толерантны. Подход, описанный в статье, не подойдет никому. Разумеется, если целью стоит грамотное развитие проекта.
Думаю, после прочтения заключения (под спойлером) вы лучше поймете цель этого поста, и все сразу встанет на свои места :)

Чукча не читатель – это точно, потому что кто-то не дочитал до заключения.
Но я вам больше скажу – happy path это чушь, вы должны ломать свой код в тестах. Меньше happy, больше хардкора.