Тестировать частные методы и внутренние классы с помощью NUnit?

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

Частные методы:

Если вы пытаетесь протестировать закрытые методы, это обычно означает, что вы делаете это неправильно.

Если есть функциональность, которую вы хотите протестировать, но не хотите публиковать в своем классе, код пытается вам что-то сказать. У вашего класса, вероятно, слишком много обязанностей. Вам следует серьезно подумать о том, чтобы извлечь эту частную функциональность в новый класс, написать тесты для нового класса и сделать свой старый класс частным экземпляром нового класса.

Внутренние классы:

Этот вариант более верен, особенно если вы пишете библиотеку классов для повторного использования другими. У вас могут быть классы, которые не предназначены для общего использования, но для которых вы хотите писать модульные тесты.

В этом случае взгляните на InternalsVisibleToAttribute .

Я делаю это так, что делаю все свои методы общедоступными. Я знаю, это звучит плохо, но потерпите минутку.

При использовании IoC у вас есть интерфейс для каждого класса, в котором есть какая-то логика. Таким образом, вы в основном кодируете интерфейс, а не фактическую реализацию. Это позволяет вам пометить все методы как общедоступные, и это не влияет на способ использования класса, за исключением того, что позволяет писать модульные тесты для каждого метода в этом классе.

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

Просто используйте решение, показанное здесь: Внутренний модификатор доступа C #, когда выполняет модульное тестирование

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