Здравствуйте, _hum_, Вы писали:

__>а можно для тех, кто в танке, как-то поразвернутее, или ссылку на статью, где бы эта тема раскрывалась?

Книги и статьи сами по себе быстро не помогут. Быстрее всего будет нанять на короткое время человека, который это умеет. Правда, в некоторых случаях придется дать ему полномочия применять средневековые пытки.

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

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

Вот смотри. Сейчас ваш процесс выглядит примерно так.

Тимлид: Нужно [исправить баг А|реализовать стори B|быстро что-то подправить в модуле C]
Разраб: Yes, sir!

Разработчк изменяет пару строк кода где-то очень глубоко в кишках исходников. И говорит "готово!". А тимлид "А ты проверил?". И разработчик идет курить бамбук, пока все пересобирается, чтобы потом еще полчаса вручную докликивать программу в состояние, в котором он может косвенно проверить часть функциональности внесенного изменения. Обнаруживает баг в багфиксе и все по-новому. Два часа рабочего времени жестоко убито. Мотивация утопилась в унитазе, а профессиональная гордость хлещет водяру из горла.

А вот как выглядит процесс разработки здорового человека:
Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.
Разраб: Ага, понятно, наконец-то мы будет показывать настоящее время, а не забивать его <unknown>. Так, где у нас спецификация...
(5 минут)
Разраб: Я хочу того же, что курили аффтфры спецификации протокола. Открывает Wireshark и выдергивает из сетевой сессии с прибором сообщения, содержащие оные типы. В случае отсутствия прибора или wireshark'a изобретает Hex-dump нужного PDU самостоятельно или заимствует его из спецификации, если аффтары озаботились примерами. В процессе придумывает забавные примеры невалидного элемента. Добавляет в протокола поддержку нового типа, а в проект юнит-тестов — проверку работы парсера, используюя награбленные или придуманные сырые данные. Не забывает тест, в котором на вход парсера подается мусор или специально инвалидированные данные. Щелкает "билд" на юнит-тест проекте. Оный собирает измененную либу парсера протокола, собирается сам и запускается. В консоли — 2 failed tests, которые разработчик нарочно зафейлил, чтобы проверить сам себя. Исправляет проваленные тесты, добавляет новые для граничных условий и обнаруженных серых пятен в спецификации, перезапускает билд. Через 5 минут — XXX tests passed.

В итоге — полностью реализовананя новая функциональность, покрытая тестами и даже в некоторых случаях прошедшая regression — ранее написанные тесты покажут, если новая функциональность вносит breaking change. Причем, за время, которого не хватило бы на полную сборку проекта и хотя бы один ручной тестовый прогон. Причем, проект автоматически прогоняет даже такие условия, которые во время ручного теста проверить невозможно.

Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!