зависит от того, что именно нужно получить в результате.

кстати, а что такое "нормальное тестирование" ?

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

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

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

я сделал так:
1.
сначала покрыл тестами функционал компонентов работы с файловой системой.
там все просто: создать/удалить файл/каталог.
и что бы это выполнялось плюс/минус стабильно.
(аппаратными проблемами можно пренебреч)

2.
для гуя сбоку прилепил свою статическую систему сообщений,
что бы можно было "нажимать на кнопки" программно.
(MFC, родную систему сообщений для этих целей задействовать не получилось).


далее реализовал такую штуковину.

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

примерно такой дизайн:


вот это вот как называется?

Этот подход продиктован практической целесообразностью. ЧТО и КАК тестировать - это специфика проекта, в одном случае нужен один способ, в другом - иной. Иногда и дебаг через принтф дает очень много. Вы же не применяете один и тот же std::vector<double>, например, на все случаи жизни? Почему с тестированием должно быть по другому?

Как Вы с помощью "некоммерческого" ТДД протеституете, например, коммуникацию с роботом? А GUI приложения? А систему, принимающую решения в реальном времени?

Правильно! Вот и Вы пришли к тому же - ТДД не может быть применимо для тестирования всего подряд (о чем так любят говорить особо упоротые адепты и сейлс-менеджеры). От себя скажу даже больше - там, где мне довелось работать, я ни разу, никогда не видел и не слышал, чтобы от ТДД был какой-либо профит. Проблемы - да. Пользы - нет. Либо потеря денег, либо времени, либо того и другого.

Сейл вообще не догадывается что это такое.
А я лично сам увидел. Особенно в больших проектах, с миллионами строк кода. В случае, когда жирная апликуха как-то интересно падает после 15 минут работы, с юнитестированием решается намного легче.
Или рефакторинг. Вот пример. Такого плана. Был себе движок для парсинга одного интересного файл. В моем случае информация о версиях. Номера версий изначально сохранялись в формате X.Y.Z. Тут сказали, что надо переделать на обычный X.Y.build. Как без юнит-тестов очень просто. Надо парсер версии переделать. Потом брать приложение, которое юзает это делать и проверять. Есть два приложения. Начали на одном тестить, вроде все хорошо. начали на втором тесть. Все хорошо. Дошло дело до приемочного тестирования. Тестировщики поковырялись и оказывается, что если к версии билда добавить буковку, хрен работает. Чтобы воспроизвести, надо сделать десяток телодвижений. Если бы были юнит-тесты, то скорее всего, там бы такой кейс был. А если не было, то добавить можно было проще. Т.е. когда уже поменяли функционал, запустил тесты и все. Минус одна проблема. Но нет, вместо того чтобы написать несколько простеньких строк текста, мы себе усложнили жизнь. Если бы таки случаев единицы. Ага, их немерено.

Проблема только одна: разработчикам лень писать примитивный код. В юинт-тестах ничего интеллектуального нет. В некоторой степени рутинная работа. Но так некоторые говорят что нафиг этот git.
По поводу потери времени, тысячу раз писал, что это компенсируется в будущем. Пример из одной конторки.
Когда только переходили на новый компилятор студии, сразу начинались проблемы. Любит мелкомягкий загрузит ненужной работой. Там где юнит-тесты были, проблемы решались в раз 5=-10(!) быстрее. И проблем было существенно меньше было. Старый код, где юнит-тестов не было, иногда отгрызал месяцы работы. 

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

Каждый раз поражаюсь тому бреду, что пишет Igors.