Я думаю, что должен быть задан более фундаментальный вопрос: почему вы пытаетесь сначала протестировать приватный метод? Это запах кода, когда вы пытаетесь протестировать закрытый метод через открытый интерфейс этого класса, тогда как этот метод является частным по причине, так как это деталь реализации. Нужно заботиться только о поведении открытого интерфейса, а не о том, как он реализован под прикрытием.
Если я хочу проверить поведение закрытого метода, используя обычные рефакторинги, я могу извлечь его код в другой класс (возможно, с видимостью на уровне пакета, поэтому убедитесь, что он не является частью общедоступного API). Затем я могу проверить его поведение в изоляции.
Продукт рефакторинга означает, что закрытый метод теперь является отдельным классом, который стал соавтором исходного класса. Его поведение станет понятным благодаря собственным модульным тестам.
Затем я могу посмеяться над его поведением при попытке проверить исходный класс, чтобы затем сосредоточиться на проверке поведения открытого интерфейса этого класса, а не на проверке комбинаторного взрыва открытого интерфейса и поведения всех его закрытых методов. ,
Я вижу это аналогично вождению автомобиля. Когда я веду машину, я не еду с поднятым капотом, поэтому я вижу, что двигатель работает. Я полагаюсь на интерфейс, который обеспечивает автомобиль, а именно на счетчик оборотов и спидометр, чтобы знать, что двигатель работает. Я полагаюсь на то, что машина действительно движется, когда я нажимаю педаль газа. Если я хочу проверить двигатель, я могу проверить его изолированно. : D
Конечно, непосредственное тестирование частных методов может быть последним средством, если у вас есть унаследованное приложение, но я бы предпочел, чтобы унаследованный код был реорганизован для обеспечения лучшего тестирования. Майкл Фезерс написал прекрасную книгу на эту тему. http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
pre-historic
с точки зрения интернет-лет, но модульное тестирование частных методов теперь легко и просто: Visual Studio создает необходимые классы доступа, когда это необходимо, и предварительно заполнив логику тестов фрагментами, чертовски близкими к тому, что можно пожелать для простых функциональных тестов. Смотрите, например. msdn.microsoft.com/en-us/library/ms184807%28VS.90%29.aspx