Лирика. "TDD" как обратная сторона "квадратов"

Про "квадраты" и "стрелки" я немного поразглагольствовал вот тут - http://programmingmindstream.blogspot.ru/2014/01/uml.html

Теперь хочется немного "полить воду" про мою ЛЮБИМУЮ тему - "разработка через тестирование".

Или "разработка на костылях тестов" :-) что - ВЕРНЕЕ.

Ну во-первых "хорошая тестируемость классов ведёт к хорошей их архитектуре".

Про это писал Тепляков:
http://programmingmindstream.blogspot.ru/2014/01/blog-post_3560.html
http://programmingmindstream.blogspot.ru/2014/01/blog-post_626.html

И ещё один автор:
http://18delphi.blogspot.ru/2013/11/blog-post_1441.html

Приведённые выше авторы озвучили ОДНУ "банальную" мысль, о которой я ДОЛГО думал, но никак не смог озвучить САМ.

А именно:
"Лакмусовая бумажка архитектурного решения

Я неоднократно писал о лакмусовой бумажке хорошего дизайна. Когда я рассматриваю дизайн класса или модуля, то стараюсь понять насколько он является цельным и слабосвязным (все те же low coupling и high cohesion) с помощью юнит-тестов. Если их написать невозможно или они будут невменяемыми, то это говорит мне, что с дизайном что-то не то.

А как определить качество архитектурного решения? Чтобы понять, как далеко некоторое решение проникло (или проникнет) в разные части системы, я задаю себе такой вопрос: «А что если я ошибся и мне придется изменить это решение в будущем? Какие будут последствия?». Если некоторое решение размазано ровным слоем по всему приложению, то стоимость его изменения будет огромной, а значит это решение является архитектурным."

Повторю ЕЩЁ раз. Как Я САМ это понимаю - "хорошо спроектированный класс - хорошо тестируется и НАОБОРОТ хорошо тестируемый класс - ХОРОШО спроектирован".

Ну ТАК я ДЛЯ СЕБЯ это ТЕПЕРЬ понимаю.

Примеров "из жизни" - у меня есть масса. Поверьте мне на слово :-) Для "особо интересующихся" - я могу попробовать собрать "дайджест".

Кстати слово "класс", тут не стоит воспринимать БУКВАЛЬНО. За ним может "маскироваться" и реальный проектный класс, и библиотека, и подсистема и проект.

Но это не всё что я хотел сказать.

Хочу сказать ещё одну "банальную" мысль. Уже НЕ РАЗ повторенную "классиками", но я ПРОЧУВСТВОВАЛ её на СЕБЕ.

Тесты это НЕ ТОЛЬКО (да и не столько) способ "поверки" правильности кода и его соответствия ТЗ.

Тесты это ещё и "пример использования" проектных классов и архитектурных решений.

У меня есть много кода, который покрыт тестами, но "написан давно" и НЕ ВМЕЩАЕТСЯ ни в хранилище "графических образов", ни в хранилище "строк кода" в моём мозгу.

Но! ПОСКОЛЬКУ этот код ХОРОШО и плотно покрыт тестами - мне и НЕ НАДО "его помнить".

Я ВСЕГДА могу посмотреть на ТЕСТЫ и понять - "как это работает" и "зачем это нужно".

ВСЁ! Мне НЕ НАДО "помнить код" и его детали.

Мне ДОСТАТОЧНО взят тесты и "перезагрузить" мой "кеш мозга".

ОЧЕНЬ УДОБНО. Для МЕНЯ ЛИЧНО.

Если кому-то этот подход - ИНТЕРЕСЕН - обращайтесь - могу попробовать и вас "прозомбировать".

P.S. А тут за рамками "выступления" осталось "аспектно-ориентированное программирование".

P.P.S. в том же самом проекте, где "нет UML" - нет и "нормальных тестов". И отчасти поэтому - он "тяжело программируется". Хотя и в РАЗЫ меньше других проектов.