da17PetroNotC Sharp, а я подумал и понял идею о том, что не надо тестировать private методы. Если еще смогу придумать зачем это надо, пока все понял.

Это ни зачем и никогда не надо.
Eсли класс нельзя на 100% покрыть тестами через его не приватный интерфейс - у тебя плохой дизайн класса. всегда. без исключений.
Cледствия:
1. если без PowerMock никак, то что не так
2. если в классе надо ослаблять видимость (например с private на package-private) только ради тестирования, то что-то не так
3. да, именно поэтому, Dependency Injection всегда и только - через конструктор
4. да, именно поэтому, private @PostConstruct/@PostLoad и т.п. - отвратительный anti-pattern которого надо избегать любой ценой
5. вообще любой вид инъекции в приватные поля и или методы - фу таким быть. И то что так можно даже в родных API (JPA, JAXB и т.д.) не оправдание

Stanislav BashkyrtsevЛогику очень часть неудобно покрывать через public интерфейс. Потому как наружу класс может отдавать только конечные результаты вычислений, а нам удобней протестировать сначала промежуточные результаты. В итоге нам приходится идти на поводу у тестов ухудшая дизайн: разбивать логику на доп классы или же открывать какие-то методы.

Реальный пример: есть робот который умеет переливать жидкость из пробирок в другие пробирки. Одна из команд представленна в виде: ВсосатьЖидкость(сколько, откуда, еще доп параметры). Робот принимает на вход CSV, соответственно классу нужен только один публичный метод: toCsv(). Но в тестах парсить CSV для проверки расчетов очень не удобно из-за чего приходится открывать кой-какие внутренности.
Это вот как раз и есть то, как делать нельзя. Никогда.
Вы тут фактически сказали "мне не удобно тестировать через честное паблик API класса, поэтому я буду срезать углы".
Тем самым закладываются сразу две мины:
1. вы протестировали класс не так как он будет реально использоваться.
2. вы подставили людей, которые при рефакторинге private кишок класса, напорятся на какие-то странные тесты.

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

Но тестировать приваты - это не номральный путь. В нормальном проекте такое никогда не пройдет code review.

Stanislav BashkyrtsevЯ протестирую его и через public API тоже. Но таких тестов я напишу меньше потому как мне останется проверить лишь то что в строку все собирается верно. А саму математику я смогу протестировать нарушив инкапсуляцию.

При всем уважении, я вашу аргументацию не понимаю и не принимаю.
Если для вас нарушение инкапсуляции это нормально - то мы в разных мирах.

Вы, уже несколько раз написали, что (в вашем примере) так делается потому что через public API тестировать сложно.
Но с каких пор "сложно" стало аргументом в пользу нарушения инкапсуляции?
это аргумент ровно в пользу того, что надо что-то менять чтобы сложно не было.

Stanislav BashkyrtsevА если моему коллеге придется потратить доп день на написание сложных тестов в которых еще попробуй разберись потом

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

возвращаюсь к вашему примеру с роботом.
мне отсюда конечно сложно судить, но я бы это просто на два класса разбил:
1. класс который делает расчеты и возвращает их в виде какой-то "простотестируемой" структуры данных
2. класс который по этой структуре данных генерирует CSV

Stanislav BashkyrtsevЭто уже какое-то новое правило, я тут идею не совсем понял. Почему сложные тесты - это сигнал плохого дизайна? Я видел много простых тестов в ужасных проектах. И там же видел много сложных тестов. И в хороших проектах видел и те, и другие. В общем не замечал пока никакой корреляции.

мой опыт как раз обычно четко показывал эту зависимость.
к самим unit test-ам обычно предъявляют ряд требований. как минимум: Stateless, Easy to write, Readable, Reliable, Fast, "unit, but not integration".
и логика дальше простая:
если тест не соответствуют требованиям - менять тест, чтобы соответсвовал
если привести в соответствие не удается из-за тестируемого кода - менять код, чтобы тест соответсвовал

отсюда появляется понятие Untestable Code и разные проистекающие из этого понятия anti-patters.

"Unit tests also aid the design" (c) Robert C. Martin (Uncle Bob)

Leonid Kudryavtsevp.s. Что такое "SingleResp/OpenClosed" не знаю, фразы не понял.

single-responsibility principle
open–closed principle

Stanislav BashkyrtsevЯ ждал когда будет предложен этот вариант. Ведь именно он якобы решает все проблемы: и тестировать проще, и инкапсуляцию можем соблюдать. Но:
1. Если этот доп класс будет public, то тут два варианта:
1.а Мы его предаем в конструктор тому кто создает CSV. В таком случае мы усложнили клиентский код. Т.е. ради тестов мы усложнили прод код.
1.б Мы его создаем внутри класса который в итоге генерит CSV. И если мы их тестируем отдельно, то мы предполагаем что CSV класс использует класс вычислениями и тем самым опять же нарушаем инкапсуляцию.
2. Если этот доп класс будет package private, то:
2.а Мы все равно тестируем не Public API. Т.е. по сути это то же самое что тестировать не public метод.
2.б То же что и в 1.б

я бы сделал примерно так:
1. новый публичный метод(e.g. getResults()), который возвращает результаты в виде какой-то удобной (и unmodifiable) структуры,
(ничего плохого а таком методе нет: он не раскрывает никаких кишок класса; по сути, это те же данные, которые клиенты уже получают посредством toCsv(), просто в другом формате )
2. новый класс (e.g. CSVWriter), для генерации CSV, который получает эту новую структуру, в конструктор (или параметр метода, не суть)
3. меняем метод toCsv(): он теперь использует новый класс (e.g. new CSVWriter(this.getResults()).write() )
что получилось:
1. новый метод дает нам данные в удобной для тестирования форме
2. новый класс (e.g. CSVWriter) даже не надо тестировать: он будет протестирован уже существующими тестами для toCsv()
3. никакого изменения сложности для клиентов не произошло; для них вообще ничего не поменялось
4. все гораздо лучше с точки зрения single-responsibility principle
5. приоткрыта дверца в сторону поддержки других форматов вывода

это конечно далеко от идеала, но даже так, сильно лучше чем было. IMHO

Stanislav BashkyrtsevНе верь всему что пишут на заборах.

вот зря вы так.
Robert Martin написал несколько хороших книжек и ввел в обиход понятие Clean Code.
да, не все что он пропагандирует бесспорно, но, в целом, он говорит правильные вещи