Как Вы тестируете закрытые методы с NUnit?

Общий шаблон для записи модульных тестов должен только протестировать открытые методы.

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

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

Это может быть корректно, чтобы переместить их в класс помощника и обнародовать их там. Этот класс не может быть представлен Вашим API.

Этот путь тестовый код никогда не смешивается с Вашим кодексом публичного права.

А подобная проблема тестирует частные классы т.е. классы, которые Вы не экспортируете из своего блока. В этом случае можно явно сделать блок тестового кода другом производственного блока кода с помощью атрибута InternalsVisibleTo.

Возможно протестировать закрытые методы путем объявления опытной сборки как друга блок целевого блока, который Вы тестируете. Посмотрите ссылку ниже для деталей:

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

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

, Как был сказан, хотя, Вы действительно не должны должны быть тестировать закрытые методы. Вы более, чем вероятный хотите осуществить рефакторинг свой код в меньшие стандартные блоки. Одна подсказка, которая могла бы помочь Вам, когда Вы приезжаете для рефакторинга, должна попытаться думать о домене, что система касается, и думайте о 'реальных' объектах, которые населяют этот домен. Ваши объекты/классы в Вашей системе должны иметь отношение непосредственно к реальному объекту, который позволит Вам изолировать точное поведение, что объект должен содержать и также ограничить обязанности по объектам. Это будет означать, что Вы осуществляете рефакторинг логически, а не только позволить протестировать конкретный метод; Вы будете в состоянии протестировать поведение объектов.

, Если Вы все еще чувствуете потребность протестировать внутренний тогда, Вы могли бы также хотеть рассмотреть насмешку в своем тестировании, как Вы, вероятно, захотите сфокусироваться на одной части кода. Насмешка состоит в том, где Вы вводите зависимости от объектов в нее, но введенные объекты не являются 'реальными' или производственными объектами. Они - фиктивные объекты с hardcoded поведением облегчить изолировать поведенческие ошибки. Носорог. Насмешки являются популярной свободной платформой насмешки, которая по существу запишет объекты для Вас. TypeMock.NET (коммерческий продукт с доступным выпуском сообщества) является более мощной платформой, которая может дразнить объекты CLR. Очень полезный для насмешки классов SqlConnection/SqlCommand и Таблицы данных, например, при тестировании приложения базы данных.

, Надо надеяться, этот ответ даст Вам немного больше информации, чтобы сообщить Вам о Поблочном тестировании в целом и помочь Вам получить лучшие результаты Поблочного тестирования.

Главная цель поблочного тестирования состоит в том, чтобы протестировать открытые методы класса. Те открытые методы будут использовать те закрытые методы. Поблочное тестирование протестирует поведение того, что общедоступно.

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

Вы просто не должны тестировать ничего, что это не общедоступно.

, Если у Вас есть некоторые внутренние методы и свойства, необходимо рассмотреть или изменение, что общественности, или поставлять тесты с приложением (что-то я действительно не вижу как проблема).

, Если Ваш клиент в состоянии выполнить Набор тестов и видеть, что код Вы поставили, на самом деле "работает", я не рассматриваю это как проблему (как долго, поскольку Вы не отдаете свой IP через это). Вещи, которые я включаю в каждый выпуск, являются отчетами о тестировании и кодируют отчеты о покрытии.

Я сделал бы пакет закрытых методов видимым. Тем путем Вы сохраняете его довольно частным в то время как все еще способность протестировать те методы. Я не соглашаюсь с людьми, говорящими, что открытые интерфейсы являются единственными, которые должны быть протестированы. Часто существует действительно критический код в закрытых методах, которые не могут быть правильно протестированы, только пройдя внешние интерфейсы.

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

я - парень Java btw, таким образом, пакет visiblilty можно было бы назвать чем-то совершенно различным в C#. Будьте достаточны, чтобы сказать, что это - когда два класса должны быть в том же пространстве имен для доступа к тем методам.