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

K>>А как же Test First?
A>Думаю, все предыдущие рассуждения можно рассматривать в контексте <YouFavoriteUnitTestFramework> — акцент стоит не на cppunit, а на не самоделках, тыкскызыть.

Меня, когда я увидел эту ветку, серьезно мучило желание спросить, а понимает ли вопрошающий что такое эти unit-тесты и для чего они используются. Но сдержался
Не, в принципе все верно, и даже в Test Infected описан такой подход: сначала что-то пишем, потом тестируем, если это что-то где-то ломается. Но, тут, как мне кажется, есть некоторая доля лукавства: код, приведенный в статье, один к одному совпадает с кодом, полученным с помощью Test Driven Development и описанным в книге Кента Бека. То есть, код, тестируемый в статье и преподносимый как Code Driven, на самом деле разработан с помощью TDD. Это и есть та доля лукавства, о которой я говорил (можно попытаться прикинуть и причины этого лукавства — например, популяризация). А вот следствия этого лукавства, как это часто бывает, идут далеко: как можно получить код, который легко тестировать? По-моему — только задумавшись об этом при написании кода. Людей, которые могут вот так, слету, написать красивый, расширяемый и легко поддающийся тестированию код я пока еще не встречал. Я бы такого человека назвал гением. Так их называет и Бек (не дословно): "TDD — для середняков. Гениям он не нужен, а тупицам — не поможет". Поэтому остается второй вариант — начинать собственно с тестов. Что в большинстве случаев и приводит к желаемым результатам.