Автоматизированное тестирование - миф?

на написание юнит-тестов просто физически нет времени

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

в одну планируемую задачу не засунуть

А это проблемы менеджера/тимлида. Который потом будет оправдываться почему апдейт из 3х строк на легаси занимает в N больше времени, чем на хелловордах.

TDD не катит, потому что это такой процесс без конца

просто не умеешь в тестирование, не надо этого стыдиться

Отговорка такая: там логики для непосредственно юнит-тестов с гулькин нос, и это прямо перед релизом можно быстро проверить ручными интеграционными и функциональными тестами.

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

логики для непосредственно юнит-тестов с гулькин нос

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

когда оно заведось в проде

Тогда используется мониторинг, а не тесты. Каждой задаче свой инструмент.

ломаться там особо и нечему

Но это вторая любимая отмазка говнокодеров

Так что коротко - нет, не миф, а часть SDLC, для тех кто рубит бабос на конкурентном рынке.

У тебя какая-то мешанина.

Автоматизированное тестирование

Делают отдельно тестировщики - автоматизаторы.

подход «test before» типа TDD

Делают разработчики в рамках юнит-тестов. Затраты на юнит-тесты включаются в стоимость разработки фичи. Автоматизированное end-to-end тестирование конечно же не входит в эту оценку, его делают уже отдельно тестировщики в рамках отдельных задач.

Т.е. когда оно заведось в проде, ломаться там особо и нечему.

Тогда может и проблемы никакой нет? Если бизнес устраивает, что проблемы на развёртывании фиксятся внедренцами / админами, то это его (бизнеса) выбор.

Да, да. Ручными тестами. Приносишь свой горящий кровь из зданицы релиз тестировщикам, а они у тебя спрашивают - а что там поменялось. Говоришь им. Они это и тестирует. А то что там ещё задело аналитику или отчетность не видят, потому что ну ты ж это не менял? А если у тебя пайплайн проверяет, то ему пофиг что ты там правил, он проверяет всё на что написаны тесты

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

Там несколько клиентов, которые платят большие деньги. С другой стороны, если что-то пойдет не так в проде, убытки будут существенными. Поэтому обеспечивается «готовность техподдержки 24х7х365», и иногда эта техподдержка доходит до программистов.

Конфликтующие фичи либо реализуются в рамках существующего API, либо создаётся новый API.

Ты путаешь теплое с мягким. АТ это не про стабильный и беспроблемный прод 24х7х365, а про быстрые и предсказуемые релизы.

Всё это относится к решению проблем, в т.ч. и с кодом.

Еще раз, описанные проблемы решает тестирование, а автоматизация лишь ускоряет процесс, делает его менее субъективным. Если сейчас в тестировании бардак, то ты получишь только автоматизированный бардак.

прямо перед релизом можно быстро проверить ручными интеграционными и функциональными тестами

это просто так не работает, иначе бы не было целой специальности QA инженеров

это просто так не работает, иначе бы не было целой специальности QA инженеров

Это какие-то 90е и Водопадная архитектура. В 2026г. программист делает всё: от архитектуры до техподдержки.

Ну, нет времени и нет времени. В чём проблема?

В 2026г. программист делает всё: от архитектуры до техподдержки

Вот теперь всё встало на свои места, эникейство головного мозга.

просто физически нет времени

если что-то пойдет не так в проде, убытки будут существенными

Чисто для усиления фейспалма

Вот теперь всё встало на свои места, эникейство

Ну, это преждевременное обвинение. Более вероятно, что продукт настолько мал по фичам, что никаких отдельных тестировщиков / админов нет, и на разрабах лежит весь цикл ("тыжпрограммист!") - от разработки до запуска в прод.

К 2К26 это, конечно, отношение не имеет. Скорее наоборот, дух начала нулевых.

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

Как думаете, Леннарт Поттеринг писал когда-нибудь юнит-тесты?

если в конторе нагрузка на программистов рассчитана так, что на написание юнит-тестов просто физически нет времени, а подход «test before» типа TDD не катит

тогда появляется замечательный вопрос - а на основании чего платится зарплата и выделяются фонды?

если исключительно от отзывов тим-лидов, пм-ов и прочей менеджерской нечисти, то бизнес накрылся

чтобы процесс работал должна быть объективка и чем больше тем лучше

А на сишке юнит-тесты это вообще дикая работа, там же и нормальных мок-фреймворков нет

"Нормальных" - это очень мутное определение, слабо связанное с техническими характеристиками.

Для "чистого" си есть https://libcheck.github.io/check/

Но код на чистом си прекрасно проверяется и https://google.github.io/googletest/

Это какие-то 90е и Водопадная архитектура. В 2026г. программист делает всё: от архитектуры до техподдержки.

Опять ты всё перепутал. Водопад - это релиз финальной версии, а аджайл - релиз прототипа. Парадигма разработки не руководит количеством физических работников, она только заведует регламентом самих работ.

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

Для этого нужен архитектор, а не тесты.

Автоматизированное тестирование - миф?

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

Вот. Такой ответ хотел получить.

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

Автоматизированное тестирование - миф?

В суровом продакшене да, миф.

Нет, не миф. Если у ПО одна инсталляция (включая множество инстансов в рамках одной организации), на автоматизированном тестировании можно сэкономить, поселив программистов в серверной.

Но если ПО тиражируемое - без а. т. далеко не уехать.

В 2026г. программист делает всё: от архитектуры до техподдержки.

Это либо стратап на 2,5 человек, либо заказчик внутренний. В продуктовых компаниях крупнее 20 человек, где работал последние 15 лет, всегда были отдельные тестировщики. Вот когда разработка на «внутреннего» заказчика, там да, там частенько на тестировщиках экономят.

В суровом продакшене да, миф.

А что по-вашему называется суровым продакшеном?

Архитектор не будет следить за бизнесовой логикой

ЛОЛ ЧТО? А как он тогда архитектуру архитектурить?

Системный дизайн довольно слабо связан с бизнесовой логикой. Если конечно ты в курсе про слои архитектуры. Иногда при отладке можно столкнуться с артефактами интеграций или разными костылями, представь что null превращается в «null» и лишь бизнес решает это баг или фича. Когда на такое поведение есть тест, вопросов не возникнет. Но ты наверное хочешь подобные мелочи тащить в пользовательскую докуменатцию или даже в модель C4?

Системный дизайн довольно слабо связан с бизнесовой логикой

Предметно-ориентированное проектирование? Не, не слышал.

Если конечно ты в курсе про слои архитектуры

Я то в курсе, а ты кажется не очень. Архитектор конечно не пишет LLD, но как минимум ревьюит и обсуждает на митинге.

Ну и в целом вот эта вот стандартная телега про «исправили в одном месте 3 строчки и где-то в другом всё упало», которую толкают как оправдание нужности тестов – это всё полная шляпа. Если так случилось, то это проблема кривой архитектуры в первую очередь. Тесты в такой системе не только не помогут, но будет только хуже (лапша с говном будет и в тестах тоже).

«исправили в одном месте 3 строчки и где-то в другом всё упало», которую толкают как оправдание нужности тестов – это всё полная шляпа

у тебя подмена понятий, но придется ответить статьей, которую я обычно в таких случаях вспоминаю: https://habr.com/ru/articles/279943/

Я то в курсе, а ты кажется не очень

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

Вася и Петя одновременно начали писать один и тот же продукт. Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру. А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение. Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы. Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов. У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента. В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком

Что, если в конторе нагрузка на программистов рассчитана так, что на написание юнит-тестов просто физически нет времени

А требование на юнит-тестирование есть? А на проектирование и описание архитектуры?

Я правильно понимаю, что можно запихать всё в функции с параметрами и если произошла ошибка, то вернуть «false» или «error» и будет понятно, где произошшла ошибка и там копать? Зачем писать тесты?

Нет, неправильно. Если честно я вообще не понял, что ты хотел сказать.

Смотри, есть ожидаемое поведение системы/программы/модуля/функции. Например, ты пишешь калькулятор, и он умеет в ф-цию сложения. У неё есть вполне ожидаемое поведение, напр. 2 + 2 = 4.

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

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

Например, нам захотелось добавить возможность складывать hex-числа с нотацией 0x. Мы можем спокойно вносить изменения в функцию сложения, ведь автоматические тесты сразу перестанут проходить когда мы все же что-то сломали, и найти изменение которое вызвало ошибку не составит труда (обычно).

Что, если в конторе нагрузка на программистов рассчитана так, что на написание юнит-тестов просто физически нет времени

Это значит что контора или делает продукт кое-как, или взялась за работу в какие-то экстремальные сроки. В любом случае это серьёзные косяки в рабочем процессе, которые потом выливаются в низкое качество продукта, плохую конкуретноспособность и далее в низкую ЗП.

Зачем писать тесты?

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

и если произошла ошибка

А кто должен понять что произошла ошибка? А если произошла, но не та, которую ты предусмотрел в коде?

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

Автоматизированное тестирование это не только юнит-тесты, но интеграционные, функционнальные и пр. (см. https://www.atlassian.com/continuous-delivery/software-testing/types-of-softw...)

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

IMHO целесообразность автотестов существенно зависит от разрабатываемого продукта. Автотест должен в итоге экономить время разработчика/тестировщика в обозримой перспективе. Если не экономит, то значит автотест тут лишний.

Вот. Такая же ситуация. Очень много внешних зависимостей у тестируемого кода, и проблемы во взаимодействии разных частей кода друг с другом, причем отдельные части либо слишком сложные (СУБД), чтобы создавать для них моки, либо проприетарные.

логики для непосредственно юнит-тестов с гулькин нос

Тупо апи без базы и логики на уровне чцть умнее прокси?