софт-то в целом поведение не поменяет, а его отдельные части — поменяют

Хорошо, тесты могут поменяться. А могут не меняться. Однако, тестирование внутренностей гарантировано ведёт к изменению тестов рано или поздно 🙂аргумент выше был в этом

Вот и напишешь тест

храни тебя б-г, чтобы я и тесты?

шучу, конечно, но тем не менее

если так рассуждать что система - черный ящик и имеет смысл только фукнциональность, и перейти от сущности "объект" к сущности "приложение", то имеет смысл тогда писать только функциональные тесты. Но это затрудниn поиск ошибок

я же спрашивал про TDD, где на каждый чих в коде ты пишешь тест сначала

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

на основе чего писать то эти приватные методы?

тут можно почитать первоисточники про TDD, т.к. современное понимание сильно извратилось и сузилось до «пиши тест перед кодом»

На основе принятых стандартов кода. Если в объекте один публичный метод (привет, service object), и он занимает 3 строки — наверное приватные и не нужны. Если 30 строк — наверное нужны, для читаемости, но тесты отдельные для них не нужны, тестируем поведение. Если в двух публичных методах есть общая часть — тоже можно выносить в приватный метод.

А если вдруг класс стал огромным — выше предлагали вынести часть в отдельный класс, и его–то протестировать

Не многие знают и помнят но TDD появлялся в том числе как та же самая "исполняемая спецификация" программы, на которой можно понимать что программа делает, и делает ли она это.

Дальнейшее ветвление привело к разным подходам, конкретно "договориться" о решении "на человеческом" перетекло в bdd и конкретно в cucmber (геркино-подобные решения), а чтобы работало и было понятно "на програмерском" в спеки разных сортов.

Но все это не имеет никакого сильного значения если ты понимаешь простую вещь о своей (любой) программе: это поток данных через интерфейсы компонентов.

cli интерфейс, cmd интерфейс, классовый / функциональный интерфейс, ui интерфейс, голосовой интерфейс абсолютли неважно - на каждый интерфейс подаются данные и что-то должно дальше моргнуить или нет.

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

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

Ориентируйся на интрефейсы (к компонентам) твоей программы и будет тебе счастье.

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

Вопрос возник потому что я начал писать с приватного метода, не с публичного

это же другой подход
Не может появиться метод на 30 строк не покрытый тестами потому что tests first

Разумеется, я отвечал на вопрос про то, как и зачм вытаскивать приватные методы

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