OCP - это когда для изменения поведения мы не лезем менять существующий код. Например, создаем новую сущность как в случае Decorator/Proxy. Или передаем Command/Strategy в класс вместо того чтоб прям в нем описывать разные стратегии поведения.

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

mad_nazgul , эм.. вообще результат не должен зависеть от того как ты к нему пришел. Кто-то использует TDD, кто-то нет, но количество и качество тестов не должно зависеть от этого.

TDD в некоторых случаях ускоряет написание prod кода. Кто-то им не пользуется и возможно в некоторых ситуациях пишет prod код медленней, соответственно это минус один бонус. Но остальные бонусы тестов (как модульных, так и других) остаются актуальными.

gmugarновый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,Ну вот ты открыл метод который до этого был private или package private (если мы его таки открывали для тестирования). Что здесь принципиально поменялось? Т.е. если этот метод лежал в старом классе, то тебе не нравилось его открывать только для тестирования. А если его перенести в другой класс и сделать public, то так открывать код чисто для тестирования - правильно. Почему?
gmugarон не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом форматеПлохо тут то что у нас +1 публичная сущность. До этого я видел с какими классами в пакете мне нужно было взаимодействовать, а теперь оказывается есть public классы которые на самом деле мне не нужны. Но эта проблема решается - твой новый класс можно сам по себе сделать package private, т.е. он не будет виден из-вне пакета. Но опять же - в чем разница метод открывать или класс?
gmugarRobert Martin написал несколько хороших книжек и ввел в обиход понятие Clean Code.Я не большой знаток Дяди Боба, все что я о нем знаю:
1. Он написал книгу на простую тему: Clean Code. Ее в общем-то много кто мог написать. Хотя это все равно полезная работа. Если бы он только по-аккуратней писал про комментирование кода.. а то многие ленивые жопы теперь не заставить документацию писать.
2. Он создал Fitnesse - самый ужасный из известных мне фреймворков для тестирования.

Наверняка он еще что-то сделал, о чем я не знаю.. Но тем не менее, полагаться на авторитет неправильно - каждую идею нужно понимать и рассказывать от себя . А не просто ссылаться на великие умы.

Я хоть и согласен с посылом что TDD не улучшает дизайн, но аргументов этих все равно не понимаю.. Причем тут jacoco к TDD, как криптография к TDD относится.. Известно что Java реализацию писали следуя TDD? Че-т сомневаюсь. То что там тесты написаны - не говорит о том как их писали. Да и криптография - это странный пример в целом, в ней многое сделано некрасиво:
а) потому что требуется хорошая производительность
б) потому что пишут security эксперты, а не программисты которые умеют писать
И уж тем более не понимаю причем тут ASN.1.. Это просто формат, это как говорить что XSD/XML некрасивые, к TDD - никакого отношения.
maytonСтартап - это бешеный темп продуцирования кода, 90% из которого завтра
уйдет в мусорное ведро.Ну во-первых, здесь описан как раз очень медленный темп (потому как 90% в мусор), а во-вторых.. Тут многие пишут про мифические стартапы, но такое ощущение что не совсем понимают что это. Стартап - это просто проект, который получил огромное финансирование еще на этапе идеи/прототипа/ранней версии (поэтому он start up). Это не гарантирует что там какой-то страшно быстрый темп и что все пишут говнокод на коленке. Наверно большинство стартапов правда разрабатываются в быстром темпе, как собственно и обычные проекты . Часто слышу что больше 90% стартапов проваливаются - возможно от части это из-за быстрого темпа.. Может даже из-за отсутствия TDD (шучу).
asv79я работаю в конторе,которая очень активно развивается и мы пишем очень много кода,зачастую я начинаю какой то модуль - и еще толком никто не знает как должно быть вообще,есть некая бизнес хотелка,по которой бегло пробежались аналитики и все -я просто не представляю ,как на такое накинуть TDDНу это лишь значит что у вас слабые аналитика, разработка и, видимо, в целом процессы. У вас в принципе мало шансов на эффективную разработку. Это не значит что у вас ничего не получится, это лишь значит что вы медленно продвигаетесь вперед.

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