الوصول إلى الأعضاء الداخليين عبر System.Reflection؟

Question

أحاول اختبار الوحدة لفصل يحتوي على العديد من الوظائف الداخلية.من الواضح أن هذه تحتاج إلى اختبار أيضًا، لكن مشروع الاختبارات الخاص بي منفصل، ويرجع ذلك أساسًا إلى أنه يغطي العديد من المشاريع الصغيرة ذات الصلة.ما لدي حتى الآن هو:

FieldInfo[] _fields = 
    typeof(ButtonedForm.TitleButton).GetFields(
        BindingFlags.NonPublic | BindingFlags.Instance | 
        BindingFlags.DeclaredOnly);
Console.WriteLine("{0} fields:", _fields.Length);
foreach (FieldInfo fi in _fields)
{
    Console.WriteLine(fi.Name);
}

يؤدي هذا إلى إخراج جميع الأعضاء الخاصين بشكل جيد، لكنه لا يعرض الأعضاء الداخلية.أعلم أن هذا ممكن، لأنه عندما كنت أعبث بالاختبارات التي تم إنشاؤها تلقائيًا والتي يمكن أن ينتجها Visual Studio، سألني عن شيء يتعلق بعرض العناصر الداخلية لمشروع الاختبار.حسنًا، أنا الآن أستخدم NUnit وأعجبني حقًا، ولكن كيف يمكنني تحقيق نفس الشيء باستخدامه؟

Answer 1

سيكون من الأنسب استخدام InternalsVisibleTo سمة لمنح حق الوصول للأعضاء الداخليين للتجميع إلى مجموعة اختبار الوحدة الخاصة بك.

إليك رابط يحتوي على بعض المعلومات الإضافية المفيدة والتجول فيه:

• عجائب الداخلية مرئية ل

للإجابة على سؤالك في الواقع ...لم يتم التعرف على العناصر الداخلية والمحمية في .NET Reflection API.هنا اقتباس من MSDN:

الكلمات الأساسية C# المحمية والداخلية ليس لها أي معنى في IL ولا يتم استخدامها في واجهات برمجة تطبيقات الانعكاس.المصطلحات المقابلة في IL هي العائلة والتجمع.لتحديد طريقة داخلية باستخدام الانعكاس، استخدم IsAssembly ملكية.لتحديد طريقة داخلية محمية، استخدم IsFamilyOrAssembly.

Answer 2

إضافة الداخليةVisibleTo سمة مستوى التجميع لمشروعك الرئيسي، مع اسم التجميع لمشروع الاختبار الثلاثة يجب أن يجعل الأعضاء الداخليين مرئيين.

على سبيل المثال، قم بإضافة ما يلي إلى التجميع الخاص بك خارج أي فئة:

[assembly: InternalsVisibleTo("AssemblyB")]

أو لاستهداف أكثر تحديدًا:

[assembly:InternalsVisibleTo("AssemblyB, PublicKey=32ab4ba45e0a69a1")]

لاحظ أنه إذا كان لتجميع التطبيق الخاص بك اسم واضح، فسوف تحتاج مجموعة الاختبار الخاصة بك أيضًا إلى تسمية قوية.

Answer 3

أعتقد أنك بحاجة إلى التساؤل عما إذا كان يجب عليك كتابة اختبارات الوحدة للطرق الخاصة؟إذا كتبت اختبارات وحدة لطرقك العامة، مع تغطية كود "معقولة"، ألا تختبر بالفعل أي طرق خاصة يجب استدعاؤها نتيجة لذلك؟

إن ربط الاختبارات بالطرق الخاصة سيجعل الاختبارات أكثر هشاشة.يجب أن تكون قادرًا على تغيير تنفيذ أي أساليب خاصة دون كسر أي اختبارات.

المراجع:

http://weblogs.asp.net/tgraham/archive/2003/12/31/46984.aspx http://richardsbraindump.blogspot.com/2008/08/should-i-unit-test-private-methods.html http://junit.sourceforge.net/doc/faq/faq.htm#tests_11 http://geekswithblogs.net/geekusconlivus/archive/2006/07/13/85088.aspx

Answer 4

يعرض الرمز الخاص بك الحقول فقط - لذا آمل ألا يُظهر أي أعضاء داخليين، حيث يجب أن تكون الحقول دائمًا IMO خاصة.(مع استثناء محتمل للثوابت.)

هل يحتوي ButtonedForm.TitleButton بالفعل على أي حقول غير خاصة؟إذا كنت تحاول العثور على الداخلية طُرق فمن الواضح أنك بحاجة إلى الاتصال GetMethods (أو GetMembers) للوصول إليهم.

وكما اقترح آخرون، InternalsVisibleTo مفيد جدًا للاختبار (وتقريبًا للاختبار فقط!).أما فيما يتعلق بما إذا كان ينبغي عليك اختبار الأساليب الداخلية - فأنا بالتأكيد أجد أنه من المفيد أن تكون قادرًا على القيام بذلك.أنا لا أعتبر اختبار الوحدة كما هو حصريا اختبار الصندوق الأسود.في كثير من الأحيان، عندما تعلم أن الوظيفة العامة يتم تنفيذها باستخدام بعض الطرق الداخلية المتصلة بطريقة بسيطة، يكون من الأسهل إجراء اختبار شامل لكل طريقة من الطرق الداخلية وبعض اختبارات "التكامل الزائف" على الطريقة العامة.

Answer 5

مبرر استخدام InternalsVisible هو في ظل ظروفي.نقوم بشراء الكود المصدري للتحكم في المخطط.لقد وجدنا حيث نحتاج إلى إجراء بعض التعديلات على عنصر التحكم بالمصدر هذا وتجميع نسختنا الخاصة.الآن للتأكد من أننا لم نكسر أي شيء، هناك بعض اختبارات الوحدة التي أحتاج إلى كتابتها والتي تحتاج إلى الوصول إلى بعض الحقول الداخلية.

هذه حالة مثالية حيث يكون InternalsVisible منطقيًا.

ولكنني كنت أتساءل ماذا تفعل إذا لم يكن لديك إمكانية الوصول إلى المصدر؟كيف يمكنك الوصول إلى المجال الداخلي؟يمكن لـ .Net Reflector رؤية هذا الرمز، ولكن أعتقد أنه ينظر فقط إلى IL.