Доступ к внутренним участникам через Систему. Отражение?
Рекомендация, по крайней мере, в 4 раза превышает интервал очистки, так как вам нужно две точки для расчета скорости и между гонками, и достаточно учесть неудачу в 4 раза.
5 ответов
Было бы более целесообразно использовать атрибут InternalsVisibleTo для предоставления доступа к внутренним элементам сборки для сборки модульного теста.
Вот ссылка с некоторой полезной дополнительной информацией и кратким описанием:
Чтобы действительно ответить на ваш вопрос ... Внутренние и защищенные не распознаются в .NET Reflection API. Вот цитата из MSDN :
Защищенные и внутренние ключевые слова C # не имеют значения в IL и не используются в API Reflection. Соответствующие термины в IL - это семья и собрание. Чтобы определить внутренний метод с помощью Reflection, используйте свойство IsAssembly . Чтобы определить защищенный внутренний метод, используйте IsFamilyOrAssembly .
Добавление атрибут уровня ассемблера InternalsVisibleTo к Вашему основному проекту, с Именем сборки thre тестового проекта должен сделать внутренних участников видимыми.
, Например, добавляют следующее к Вашему блоку вне любого класса:
[assembly: InternalsVisibleTo("AssemblyB")]
Или для более определенного предназначения:
[assembly:InternalsVisibleTo("AssemblyB, PublicKey=32ab4ba45e0a69a1")]
Примечание, если Ваш блок приложения имеет строгое имя, Ваша опытная сборка, должны будут также сильно назвать.
Я думаю, вам нужно спросить, следует ли вам писать модульные тесты для частных методов? Если вы пишете модульные тесты для своих открытых методов с «разумным» охватом кода, разве вы уже не тестируете какие-либо частные методы, которые должны вызываться в результате?
Привязка тестов к закрытым методам сделает тесты более хрупкие. Вы должны иметь возможность изменять реализацию любых частных методов, не нарушая никаких тестов.
Ссылки:
http://weblogs.asp.net/tgraham/archive/2003/12/31/46984.aspx http: //richardsbraindump.blogspot .com / 2008/08 / should-i-unit-test-private-method.html http://junit.sourceforge.net/doc/faq/faq.htm#tests_11 http://geekswithblogs.net/geekusconlivus/archive/2006/07/13/85088.aspx
Ваш код только показывает поля - таким образом, я надеялся бы, что он не покажет никаким внутренним участникам, поскольку поля должны всегда быть частным IMO. (За потенциальным исключением констант.)
Делает ButtonedForm. TitleButton на самом деле имеют какие-либо нечастные поля? При попытке найти внутренним методы тогда, очевидно, необходимо звонить GetMethods (или GetMembers) для достигания их.
, Поскольку другие предложили, InternalsVisibleTo очень удобно для тестирования (и почти только для тестирования!). Что касается того, необходимо ли тестировать внутренние методы - я, конечно, нахожу полезным быть в состоянии сделать так. Я не расцениваю поблочное тестирование, как являющееся исключительно тестирование методом "черного ящика". Часто, когда Вы знаете, что общедоступная функциональность реализована с помощью нескольких внутренних методов, соединенных простым способом, легче сделать полное тестирование каждого из внутренних методов и некоторых тестов "псевдоинтеграции" на открытом методе.
Обоснование использования InternalsVisible в моих обстоятельствах. Мы покупаем исходный код в Chart Control. Мы нашли, где нам нужно внести некоторые изменения в этот источник контроля и скомпилировать нашу собственную версию. Теперь, чтобы убедиться, что мы ничего не сломали, мне нужно написать несколько модульных тестов, которым нужен доступ к некоторым внутренним полям.
Это идеальный случай, когда InternalsVisible имеет смысл.
Мне было интересно, однако, что вы делаете, если у вас нет доступа к источнику? Как вы могли добраться до внутреннего поля? .Net Reflector может видеть этот код, но я думаю, он просто смотрит на IL.