سؤال

هل هناك طريقة للسخرية من بناء الكائنات باستخدام JMock في Java؟

على سبيل المثال، إذا كان لدي طريقة على هذا النحو:

public Object createObject(String objectType) {
    if(objectType.equals("Integer") {
        return new Integer();
    } else if (objectType.equals("String") {
        return new String();
    }
}

هل هناك طريقة للسخرية من توقع بناء الكائن بطريقة الاختبار؟

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

لذا بدلاً من:

assertTrue(a.createObject() instanceof Integer);

يمكن أن أتوقع أن يتم استدعاء مُنشئ معين.فقط لجعلها أكثر وضوحًا، والتعبير عما يتم اختباره بالفعل بطريقة أكثر قابلية للقراءة.

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


لمزيد من الخلفية قليلا:

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

ربما أقرب إلى ما أبحث عنه بالفعل هو:هل هناك طريقة للسخرية من فصل دراسي بأكمله (باستخدام CGLib) بضربة واحدة، دون تحديد كل طريقة للتخلص منها؟

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

تخميني هو لا، لأن ذلك سيكون معقدًا جدًا.لكن معرفة أنني أنبح الشجرة الخطأ أمر ذو قيمة أيضًا :-)

هل كانت مفيدة؟

المحلول

الشيء الوحيد الذي يمكنني التفكير فيه هو تشغيل طريقة الإنشاء في كائن المصنع، وهو ما قد تسخر منه.

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

نصائح أخرى

يمكن لـ jmockit القيام بذلك.

انظر إجابتي في https://stackoverflow.com/questions/22697#93675

للأسف، أعتقد أنني مذنب بطرح السؤال الخطأ.

يبدو المصنع البسيط الذي كنت أحاول اختباره كما يلي:

public Wrapper wrapObject(Object toWrap) {
    if(toWrap instanceof ClassA) {
        return new Wrapper((ClassA) toWrap);
    } else if (toWrap instanceof ClassB) {
        return new Wrapper((ClassB) toWrap);
    } // etc

    else {
        return null;
    }
}

كنت أطرح السؤال عن كيفية العثور على ما إذا تم استدعاء "new ClassAWrapper ()" لأنه كان من الصعب الحصول على الكائن toWrap في اختبار معزول.والغلاف (إذا كان من الممكن تسميته بذلك) غريب نوعًا ما لأنه يستخدم نفس الفئة لتغليف كائنات مختلفة، فقط يستخدم مُنشئات مختلفة[1].أظن أنني لو طرحت السؤال بشكل أفضل بعض الشيء، لكنت قد تلقيت الإجابة بسرعة:

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

لدي الآن حل جيد للمشكلة العاجلة، شكرًا!

[1] إن فتح السؤال حول ما إذا كان ينبغي إعادة هيكلة هذا الأمر هو خارج نطاق مشكلتي الحالية :-)

هل أنت على دراية حقن التبعية?

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

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

حقن التبعية أو انقلاب السيطرة.

وبدلاً من ذلك، استخدم نمط تصميم Abstract Factory لجميع الكائنات التي تقوم بإنشائها.عندما تكون في وضع اختبار الوحدة، قم بإدخال Testing Factory الذي سيخبرك بما تقوم بإنشائه، ثم قم بتضمين رمز التأكيد في Testing Factory للتحقق من النتائج (عكس التحكم).

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

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

آمل ألا يكون هناك شيء.من المفترض أن تسخر المحاكاة من الواجهات التي لا تحتوي على مُنشئات...مجرد أساليب.

يبدو أن هناك شيئًا خاطئًا في أسلوبك في الاختبار هنا.هل هناك أي سبب وراء حاجتك لاختبار استدعاء المُنشئين الصريحين؟
يبدو التأكد من نوع الكائن الذي تم إرجاعه أمرًا جيدًا لاختبار تطبيقات المصنع.تعامل مع createObject كصندوق أسود..افحص ما تُرجعه ولكن لا تتحكم في كيفية القيام بذلك.لا أحد يحب ذلك :)

تحديث على التحديث: أوه!تدابير يائسة للأوقات اليائسة إيه؟سأكون مندهشًا إذا سمح JMock بذلك ...كما قلت أنه يعمل على واجهات..ليست أنواع ملموسة.لذا

  • إما أن تحاول بذل بعض الجهد في جعل كائنات الإدخال المزعجة هذه "غير قابلة للتثبيت" تحت أداة الاختبار.الذهاب إلى أسفل في النهج الخاص بك.
  • إذا كان ذلك غير ممكن، فاختبره يدويًا باستخدام نقاط التوقف (أعلم أنه سيء).ثم قم بلصق تعليق "المسه على مسؤوليتك الخاصة" في منطقة مرئية في الملف المصدر والمضي قدمًا.قتال في يوم آخر.
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top