Вопросы по юнит-тестированию приватных методов

Question

В MSTest атрибут [Shadowing] помогает вам тестировать закрытый метод из другой сборки.Вот соответствующая ссылка: Какой атрибут Shadowing использует VS, когда генерирует модульные тесты?

Мои вопросы:

1. Должны ли быть закрытые методыблок тестируется отдельно?
2. Это хорошая (?) Практика - менять аксессор частного метода на internal, чтобы сделать его доступным для модульного тестирования в каком-либо другом тестовом проекте / сборке?(с использованием InternalsVisibleTo)
3. Если частные методы тестируются косвенно с помощью открытого метода, который их вызывает, можно ли его назвать «модульным» тестированием?

Answer 1

1. Нет, частные методы не должны тестироваться.Ваше приложение будет взаимодействовать только с публичным API.Таким образом, вы должны проверить ожидаемое поведение вашего класса для этого взаимодействия.Приватные методы являются частью реализации внутренней логики.Пользователи вашего класса не должны заботиться о том, как это реализовано.
2. Нет, это не хорошо.Смотри выше.Вы должны тестировать только публичный API.
3. Вы должны тестировать только публичные методы.Вам не важно, будет ли публичный метод вызывать приватный метод или нет, пока тест не будет пройден.Если тест не пройден, исправьте реализацию.Но в любом случае не тестируйте приватные методы.

ОБНОВЛЕНИЕ (как определить, что тестировать): в идеале (в тестовом подходе) тест - это первый пользователь вашего класса.Когда вы пишете тест, вы пытаетесь представить, как пользователи будут использовать ваш класс.Пользователи не будут взаимодействовать с приватными методами (Reflection - это обман).Поэтому и ваш тест, как первый пользователь вашего класса, не должен взаимодействовать с закрытыми методами.

Answer 2

Чтобы ответить на ваши вопросы кратко:

1. В общем, они не должны. В большинстве случаев ваши личные биты будут проверяться при тестировании класса контракт / публичный API. Для случаев, когда это невозможно, тестирование частного метода - это модульное тестирование, как и все остальное.

2. Это довольно часто. Хотя изменение видимости может считаться плохой идеей, это не так плохо, когда она меняется только на внутреннюю. Однако в таких подходах, как TDD, необходимость тестирования обычно приводит к вашему дизайну таким образом, что подобные «хаки» не нужны. Но, как я уже сказал, это довольно распространенное явление - вам не следует слишком беспокоиться об этом, если только он не достигнет нелепых уровней (скажем, раскрываются целые частные части классов).

3. Это юнит-тест, пока он тестирует единицу (или одну логическую концепцию ) вашего класса. Частные методы чаще всего создаются в результате рефакторингов в публичных частях, которые в большинстве случаев будут использоваться при тестировании single unit . Если вы считаете, что ваш закрытый метод больше не является единицей , это может быть вызов рефакторинга.

Также предлагаю посмотреть здесь , здесь и здесь .

Answer 3

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

Использование внутренних вместо личных может закончиться большим беспорядком, я не буду использовать этот подход.

Answer 4

Как разработчик Java, я делаю.Я тоже не меняю уровни доступа.Я использую отражение, чтобы получить доступ к закрытым методам.Мне не нужно предоставлять его моим пользователям, и мне не нужно показывать им свои модульные тесты.

Это грязный секрет Java: вы всегда можете обойти ограничения доступа с помощью отражения.Я не знаю, верно ли это для C # и .NET, но вы можете посмотреть на это, чтобы увидеть.