كيف تسخر من الفصل المختوم؟

Question

الاستهزاء بالفصول المختومة يمكن أن يكون الألم تماما.أنا أؤيد حاليا نمط المحول للتعامل مع هذا، ولكن شيئًا ما يظل غريبًا.

إذًا، ما هي أفضل طريقة للسخرية من الفصول المختومة؟

إجابات جافا هي موضع ترحيب كبير.في الواقع، أتوقع أن يتعامل مجتمع Java مع هذا الأمر لفترة أطول وأن لديه الكثير ليقدمه.

ولكن إليك بعض آراء .NET:

• لماذا تكتب البط لصالح c# develoepers
• إنشاء أغلفة للمختومة وأنواع أخرى للسخرية
• اختبارات الوحدة لـ WCF (و Moq)

Answer 1

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

أيضًا، كنت أعمل بشكل أساسي في Java خلال السنوات الأربع الماضية ويمكنني القول إنه يمكنني الاعتماد على عدد المرات التي قمت فيها بإنشاء فصل دراسي نهائي (مختوم) بيد واحدة.قاعدة أخرى هنا هي أنه يجب أن يكون لدي دائمًا سبب وجيه لإغلاق الفصل، بدلاً من إغلاقه افتراضيًا.

Answer 2

بالنسبة لـ .NET، يمكنك استخدام شيء من هذا القبيل TypeMock, ، والذي يستخدم واجهة برمجة تطبيقات التوصيف ويسمح لك بربط المكالمات بأي شيء تقريبًا.

Answer 3

أعتقد أن حيوانات الخلد, ، من Microsoft Research، يسمح لك بالقيام بذلك.من صفحة الشامات:

يمكن استخدام الشامات لالتقاط أي طريقة .NET ، بما في ذلك الأساليب غير الذروة/الثابتة في أنواع مختومة.

تحديث: يوجد إطار عمل جديد يسمى "Fakes" في إصدار VS 11 القادم والذي تم تصميمه ليحل محل الشامات:

ال إطار عمل مزيف في Visual Studio 11 هو الجيل القادم من Moles & Stubs، وسوف يحل محله في النهاية.تختلف المنتجات المزيفة عن الشامات، ومع ذلك، فإن الانتقال من الشامات إلى المنتجات المزيفة سيتطلب بعض التعديلات على التعليمات البرمجية الخاصة بك.سيكون دليل الترحيل هذا متاحًا في وقت لاحق.

متطلبات:فيجوال ستوديو 11 ألتيميت، .NET 4.5

Answer 4

المشكلة في TypeMock هي أنه يبرر التصميم السيئ.الآن، أعرف أن هذا يحدث في كثير من الأحيان لأحد آخر تصميم سيئ يخفيه، لكن السماح به في عملية التطوير الخاصة بك يمكن أن يؤدي بسهولة شديدة إلى السماح بتصميماتك السيئة.

أعتقد أنك إذا كنت ستستخدم إطار عمل ساخرًا، فيجب عليك استخدام إطار تقليدي (مثل Moq) وإنشاء طبقة عزل حول الشيء غير القابل للسخرية، والاستهزاء بطبقة العزل بدلاً من ذلك.

Answer 5

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

كما أنه يسهل تبديل تبعياتي على المدى الطويل.

Answer 6

لقد واجهت هذه المشكلة مؤخرًا وبعد القراءة/البحث في الويب، يبدو أنه لا توجد طريقة سهلة للتغلب عليها باستثناء استخدام أداة أخرى كما هو مذكور أعلاه.أو الخام في التعامل مع الأشياء كما فعلت:

• قم بإنشاء مثيل للفئة المختومة دون استدعاء المُنشئ.

• System.Runtime.Serialization.FormatterServices.GetUninitializedObject(instanceType);

• قم بتعيين قيم لخصائصك/حقولك عبر الانعكاس

• YourObject.GetType().GetProperty("PropertyName").SetValue(dto, newValue, null);
• YourObject.GetType().GetField("FieldName").SetValue(dto, newValue);

Answer 7

أتبع عمومًا طريق إنشاء واجهة وفئة محول/وكيل لتسهيل الاستهزاء بالنوع المختوم.ومع ذلك، فقد قمت أيضًا بتجربة تخطي إنشاء الواجهة وجعل نوع الوكيل غير مختوم بالطرق الافتراضية.لقد نجح هذا بشكل جيد عندما يكون الوكيل عبارة عن فئة أساسية طبيعية تحتوي على جزء من الفئة المختومة والمستخدمين.

عند التعامل مع التعليمات البرمجية التي تتطلب هذا التكيف، تعبت من تنفيذ نفس الإجراءات لإنشاء الواجهة ونوع الوكيل، لذلك قمت بتنفيذ مكتبة لأتمتة المهمة.

تعتبر التعليمات البرمجية أكثر تعقيدًا إلى حد ما من العينة الواردة في المقالة التي تشير إليها، لأنها تنتج تجميعًا (بدلاً من التعليمات البرمجية المصدر)، وتسمح بإنشاء التعليمات البرمجية على أي نوع، ولا تتطلب الكثير من التكوين.

لمزيد من المعلومات، يرجى الرجوع إلى هذه الصفحة.

Answer 8

من المعقول تمامًا الاستهزاء بالفئات المختومة لأن العديد من فئات الإطارات مختومة.

في حالتي أحاول الاستهزاء بفئة messageQueue الخاصة بـ .Net حتى أتمكن من TDD منطق معالجة الاستثناءات الرائع الخاص بي.

إذا كان لدى أي شخص أفكار حول كيفية التغلب على خطأ Moq بخصوص "الإعداد غير الصالح لعضو غير قابل للتجاوز"، فيرجى إبلاغي بذلك.

شفرة:

    [TestMethod]
    public void Test()
    {
        Queue<Message> messages = new Queue<Message>();
        Action<Message> sendDelegate = msg => messages.Enqueue(msg);
        Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate =
            (v1, v2) =>
            {
                throw new Exception("Test Exception to simulate a failed queue read.");
            };

        MessageQueue mockQueue = QueueMonitorHelper.MockQueue(sendDelegate, receiveDelegate).Object;
    }
    public static Mock<MessageQueue> MockQueue
                (Action<Message> sendDelegate, Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate)
    {
        Mock<MessageQueue> mockQueue = new Mock<MessageQueue>(MockBehavior.Strict);

        Expression<Action<MessageQueue>> sendMock = (msmq) => msmq.Send(It.IsAny<Message>()); //message => messages.Enqueue(message);
        mockQueue.Setup(sendMock).Callback<Message>(sendDelegate);

        Expression<Func<MessageQueue, Message>> receiveMock = (msmq) => msmq.Receive(It.IsAny<TimeSpan>(), It.IsAny<MessageQueueTransaction>());
        mockQueue.Setup(receiveMock).Returns<TimeSpan, MessageQueueTransaction>(receiveDelegate);

        return mockQueue;
    }

Answer 9

على الرغم من أنه متوفر حاليًا فقط في الإصدار التجريبي، أعتقد أنه من المفيد أن نأخذ في الاعتبار الرقائق سمة من الجديد إطار مزيف (جزء من فيجوال ستوديو 11 إصدار بيتا).

توفر أنواع الرقائق آلية لتحويل أي طريقة .NET إلى مفوض محدد من قبل المستخدم.يتم إنشاء أنواع الرقائق بواسطة منشئ التزييف، ويستخدمون المفوضين، الذين نسميهم أنواع الرقائق، لتحديد تطبيقات الطريقة الجديدة.تحت الغطاء، تستخدم أنواع الرقائق عمليات الاسترجاعات التي تم إدخالها في وقت التشغيل في طريقة أجسام MSIL.

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

Answer 10

هل هناك طريقة لتنفيذ فئة مختومة من واجهة ...ويسخر من الواجهة بدلاً من ذلك؟

هناك شيء بداخلي يشعر أن وجود فصول مختومة أمر خاطئ في المقام الأول، ولكن هذا أنا فقط :)