[Psycho Tiger]

Ну не знай, что-то я сомневаюсь, что для небольших инди проектов, тесты действительно так нужны. Лучше потратить это время на контент, чем на создание тестов, которые отработают один раз и будут лежать мёртвым грузом. Тем более, покрывать 100% бизнес логики, это жесть. Иногда достаточно ограничиться обычным дебагером или трейсом, для проверки внутреннего состояния модуля.

Пример от балды: игра в дурака. Что тестируем? Метод #card.canBeat(otherCard), возвращающий true/false.
1) Что нельзя бить карту другой мастью.
2) Что можно бить карту той же мастью, но выше по рангу.
3) Что нельзя бить карту той же мастью, но ниже по рангу.
4) Что можно бить что угодно козырем.

Эти 4 теста дают неплохое покрытие для этого метода. Реализовали, запустили, тесты зелёные. Что это значит? Значит что мне не нужно тестировать это вручную больше никогда. Я всегда знаю, что метод canBeat вернёт правильный результат.
После лёгкого QA-теста выяснилось, что младший козырь может бить верхний козырь – это баг. Что я делаю? Я делаю пятый тест на этот метод:
5) Козырь нижнего ранга не бьёт козыря верхнего ранга.
Это гарантия того, что этот баг больше никогда не повторится.

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

Добавлено через 3 минуты

Вот о чем и речь. Такие примеры показывают как их можно использовать, но не показывают смысла их использования.

Смысл - в простом рефакторинге и в уверенности, что новые фичи не сломают старые. Бонусом - простота разработки; например, перед тобой поставили задачу - написать калькулятор, вычисляющий длинные выражения. Единожды написав 20 тестов, которые тестируют вложенности скобок, порядок операторов, типа
1) 2 + 2 = 4
2) 2 + 2 * 2 = 6
3) (2 + 2) * 2 = 8
4) ( 2 * (3 - 2) + 4 ) * 3 = 18

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

Добавлено через 9 минут

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

@wvxvw Любопытно, почему сборка может не проходить интеграционный тест? Это ведь именно самый важный маркер, дружит ли система сама с собой. Если модуль А ожидает параметр int ID, а модуль B ему даёт string Name (для примера скажем, что типизация динамическая и ошибку в компайл-тайм не отследить) – то это как раз самое время сказать, что со сборкой что-то не то.

Вообще из этого краткого рассказа подход очень похож на тестирование в Google.