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)