Здравствуйте, xy012111.

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

1. У Вас 100% есть представление о том, что ожидается от работы метода сортировки. Например, Вы можете точно хотеть, чтобы он сортировал определенным образом данные, а в каких-то конкретных случаях делал исключения.
   
2. Этот метод сортировки может быть изменен или заменен другим в любой момент.

Я правильно понял указанные Вами условия?
Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
Вот и все: не надо тестирвоать приватные и по коду понятно, что эта штука может быть изменена, удалена. В случае необходимости, от него можно будет изолироваться.

По второй части.

Предположим у нас есть класс с двумя public-методами и очень сложной их внутренней реализацией, завязанной на 50 приватных методов. Как выглядят тесты в случае, когда тестируются приватные методы в том числе? Каких-ниьудь пара тестов на паблик, и куча кейзов на приватные методы. Сами кейзы не понятно как связаны. При этом возникает ситуация. Что приватные методы вроде как работают (тесты зеленые) и паблик методы работают (зеленые), но система нет (тестер говорит). Начинаем выяснять, и оказывается, что не покрыто одно условие, которое мы запиливаем в тесте для приватного метода.
Смотрим дальше: приходит другой девелопер, меняет приватные методы. Паблик как были зеленые, так и остались. А вот приватные он, как бы, починил. ОТдает тестеру, а он ему возвращает снова, говоря что не работает. (Опять тот же баг, что был раньше).

Теперь рассмотрим вариант с тестирование только паблик методов API.
У нас есть требования к тому, как он должен работать. Последовательно каждый из случаев имплементируется. Теперь, если поменяются внутренности, но не поменяются требования, гораздо легче понять где и что упала и поправить это.
Я допускаю, что реинкарнация тоже будет, но значительно меньше.

Здравствуйте, xy012111.

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

1. У Вас 100% есть представление о том, что ожидается от работы метода сортировки. Например, Вы можете точно хотеть, чтобы он сортировал определенным образом данные, а в каких-то конкретных случаях делал исключения.
   
2. Этот метод сортировки может быть изменен или заменен другим в любой момент.

Я правильно понял указанные Вами условия?
Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
Вот и все: не надо тестирвоать приватные и по коду понятно, что эта штука может быть изменена, удалена. В случае необходимости, от него можно будет изолироваться.

По второй части.

Предположим у нас есть класс с двумя public-методами и очень сложной их внутренней реализацией, завязанной на 50 приватных методов. Как выглядят тесты в случае, когда тестируются приватные методы в том числе? Каких-ниьудь пара тестов на паблик, и куча кейзов на приватные методы. Сами кейзы не понятно как связаны. При этом возникает ситуация. Что приватные методы вроде как работают (тесты зеленые) и паблик методы работают (зеленые), но система нет (тестер говорит). Начинаем выяснять, и оказывается, что не покрыто одно условие, которое мы запиливаем в тесте для приватного метода.
Смотрим дальше: приходит другой девелопер, меняет приватные методы. Паблик как были зеленые, так и остались. А вот приватные он, как бы, починил. ОТдает тестеру, а он ему возвращает снова, говоря что не работает. (Опять тот же баг, что был раньше).

Теперь рассмотрим вариант с тестирование только паблик методов API.
У нас есть требования к тому, как он должен работать. Последовательно каждый из случаев имплементируется. Теперь, если поменяются внутренности, но не поменяются требования, гораздо легче понять где и что упало и поправить это.
Я допускаю, что реинкарнация тоже будет, но значительно меньше. Так же, можно упустить тесты на вспомогательные классы, если они специализированы для этого модуля. Не надо писать тесты на приватные методы. Покрывается только то, что реально надо.