Unit-тесты не нужны - видео HD

Судя по комментариям переживать о том, что нейросети заменят кодеров, не стоит, т.к. это будет большой плюс. Unit-тесты пришли из TDD, а любая методика разработки ПО — это ответная реакция отрасли на усложнение ПО с целью удержания затрат на внесение изменений в продукт в каких-то приемлемых рамках. Если абстрагироваться от слова Unit и отталкиваться от словосочетания «автоматизированный тест», то тесты каждый лошпет может использовать хотя бы в качестве приемочных, чтобы быть уверенным, что код правильно выполняет хотя бы задуманное поведение. Основной плюс тестов — многократные автоматические проверки. Если вам CI не нужен, то это сильно поможет при рефакторинге свое кода и при рефакторинге легаси кода. Чтобы тесты использовать по нормальному должна быть соответствующая культура разработке, навязанная коллективу сверху, но из-за таких вот роликов это особо никому не надо, т.к. нужно вникать в детали, а большинству руководителей вникать в детали не хочется. Примерно поэтому в самой главной отечественной платформе разработки (1С) используется местами обрезанный процедурный подход, а вендор на форумах рассказывал (давно уже за этим не слежу, но думаю ничего не поменялось), что лучше знает, что нужно программерам, когда задавали вопросы о добавлении ООП.
Целенаправленное использование пользователей в качестве тестеров — это вообще без комментариев. Если репутация не важна, то почему бы и нет.
На данный момент отрасль наверно несколько раз уже переосмыслила и обобщила опыт использование тестов. Сейчас есть возможно не совершать самые грубые ошибки по их использованию. Если кому интересно, почитайте «Владимир Хориков: Принципы юнит-тестирования».

ты просто никогда не писал действительно сложный код.

Юнит-тест ещё полезен, если на этапе разработки нужно здесь и сейчас отладить какой-нибудь кусок кода в большом проекте. А так если юнит-тест не был написан во время разработки, то он скорее всего и не нужен.

какой бред.
Оценивать грамотность работы софта по интеграционным тестам — о боже. Как будто самому не дурку, а лоботомию уже оформили. Привет передаю всякие прикольные баги рантайма типа кастов, переполнений, ошибок элементарной математики и прочая херотень, которую интеграционные тесты в жизни не отловят. А если у тебя интеграционные тесты проверяют внутрянку модулей, то это уже полноценный предохранительный уровень получается. Да, гораздо «проще и дешевле», чем десяток юнит-тестов, которые отловят подобную паль и стоят копейки.
За «баг, который находится на 5 минут» тоже в голос проорал. Если баг находится на 5 минут, то это не баг даже, он действительно не стоит внимания и предварительных защит. Однако настоящие баги, которые возникают в давно отлаженных системах при расширении например (представь кодовую базу на 500+ классов общей совокупностью 6-7к строк только предметного кода) — вот эту херотень ты будешь искать полдня какими угодно тестами вообще и молиться, чтобы вой опыт и чуйка не подвели. Как раз для таких случаев, юнитесты — спасение, потому что они сразу могут показать что отлетело и почему.
В общем, для стартапов-одногодок гайд пойдёт. Для крупномасштабных систем с развитием и поддержкой из года в год — з а не гайд.

А как тогда отлавливать ошибки в коде?