اختبار الربيع بسيط للغاية في الواقع

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

كيفية دمج اختبار المشاريع المستندة إلى الربيع بشكل أفضل <BR /> باستخدام الأدوات: الربيع ، Junit ، Mockito
تخيل أن هناك مشروع الربيع يدمج بعض الخدمات الخارجية ، مثل بعض خدمات الويب المصرفية. بعد ذلك ، فإن المشكلات التي واجهتها عند كتابة حالات الاختبار لهذا المشروع واستكمال هذه الاختبارات في نظام التكامل المستمر هي نفسها في الأساس:
1. ستكون هناك معاملات في كل اختبار ، وكل معاملة تتطلب تكلفة نقدية ، والتي سيتم تحملها في النهاية من قبل العميل ؛
2. يمكن اعتبار الطلبات المفرطة الصادرة أثناء الاختبار طلبات ضارة ، والتي قد تتسبب في حظر الحساب في البنك ، مع نتيجة فشل الاختبار ؛
3. عند إجراء الاختبار باستخدام بيئة غير إنتاج ، فإن نتائج الاختبار غير موثوقة للغاية. وبالمثل ، فإن النتيجة هي أن الاختبار يفشل.
عادة ، عند اختبار فئة واحدة ، يكون من السهل حل المشكلة لأنه يمكنك عرض بعض الخدمات الخارجية للاتصال. ولكن عند اختبار عملية الأعمال الضخمة بأكملها ، فهذا يعني أنك تحتاج إلى اختبار مكونات متعددة ، وفي هذا الوقت ، تحتاج إلى دمج هذه المكونات في حاوية الربيع للإدارة. لحسن الحظ ، يتضمن Spring إطارًا ممتازًا للاختبار يتيح لك ضخ الفاصوليا من ملفات تكوين بيئة الإنتاج في بيئة الاختبار ، ولكن بالنسبة لتلك التي تسمى الخدمات الخارجية ، نحتاج إلى كتابة تطبيقات وهمية بأنفسنا. قد يكون رد الفعل الأول للأشخاص العاديين هو إعادة (تعديل) الفاصوليا التي تم حقنها بحلول الربيع خلال مرحلة الإعداد من الاختبار ، ولكن يجب النظر بعناية هذه الطريقة.

تحذير: وبهذه الطريقة ، يكسر رمز الاختبار سلوك الحاوية الخاص ، لذلك ليس هناك ما يضمن أنه سيكون نفس نتائج الاختبار في بيئة حقيقية.
في الواقع ، بدلاً من تنفيذ فئة وهمية أولاً ثم إعادة توحيدها في الحبة المطلوبة ، يمكننا السماح لـ Spring بمساعدتنا في ضخ فئة وهمية من البداية. دعونا نوضح ذلك بالرمز.
يحتوي مشروع العينة على فئة تسمى Bankservice ، والتي تمثل الدعوة إلى الخدمة الخارجية ، وفئة تسمى UserBlanceservice ، والتي تستدعي Bankservice. يتم تنفيذ Uservalustyervice بسيطة للغاية ، فقط لإكمال تحويل التوازن من السلسلة إلى النوع المزدوج.
مدونة المصدر لـ Bankservice.java:

 الواجهة العامة Bankservice {String getBalanceByEmail (سلسلة البريد الإلكتروني) ؛}

مدونة المصدر لـ BankserviceImpl.Java:

 الطبقة العامة BankServiceImpl تنفذ Bankservice {Override السلسلة العامة getBalanceByEmail (سلسلة البريد الإلكتروني) {رمي جديد غير مدعوم ("فشل العملية بسبب الاستثناء الخارجي") ؛ }}

رمز مصدر المستخدمين useralanceservice.java:

 واجهة userbaluterservice {double getAccountbalance (سلسلة البريد الإلكتروني) ؛}

رمز المصدر للمستخدمين uservicerviceimpl.java:

 الفئة العامة userbaluterserviceImpl تنفذ userbalanceservice {autowired private bankservice service ؛ Override public double getAccountbalance (سلسلة البريد الإلكتروني) {return double.valueof (bankservice.getBalanceByemail (البريد الإلكتروني)) ؛ }}

ثم يوجد ملف تكوين XML الخاص بـ Spring ، مع إضافة إعلان Bean المطلوب.
رمز مصدر ApplicationContext.xml:

 <؟ XSI: schemalocation = "http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> bankservice "/

فيما يلي الكود المصدري لفئة الاختبار userblanceserviceimpltest.java:

 Runwith (springJunit4ClassRunner.Class) contextConfiguration (مواقع = "classpath: /springtest/springockito/applicationContext.xml") فئة عامة فئة مستخدمي userblancesImplprofileTest Autowired Private Bankservice Service ؛ Test public void should anustreturnmockedbalance () {double balance = userBalusterervice.getAccountbalance ("[email protected]") ؛ Assertequals (التوازن ، double.valueof (123.45d)) ؛ }}

كما توقعنا ، تقارير طريقة الاختبار عن استثناء غير مدعوم. هدفنا الحالي هو استبدال الخدمات البنكية بتنفيذ المحاكاة لدينا. لا بأس في استخدام Mockito مباشرة لإنشاء حبوب المصنع ، ولكن هناك خيار أفضل ، استخدم إطار عمل Springockito. يمكن أن يكون لديك فكرة تقريبية قبل المتابعة.

السؤال المتبقي بسيط: كيفية حقن الزنبرك في حبة محاكاة بدلاً من حبة حقيقية ، لم يكن هناك طريقة أخرى قبل Spring 3.1 باستثناء إنشاء ملف تكوين XML جديد. ولكن منذ أن قدم Spring تعريف ملف تعريف الفاصوليا ، لدينا حل أكثر أناقة ، على الرغم من أن هذا النهج يتطلب أيضًا ملف تكوين XML إضافي خصيصًا للاختبار. فيما يلي رمز ملف التكوين testapplicationContext.xml المستخدم للاختبار:

 <؟ xmlns: mockito = "http://www.mockito.org/spring/mockito" http://www.mockito.org/spring/mockito Resource = "classpath: /springtest/springockito/applicationContext.xml"/> <beans profile = "springtest"> <mockito: mock id = "bankservice"/> </bans> </bans>

الكود المصدري لفئة الاختبار userblanceserviceimplprofiletest.java بعد إجراء تعديلات مقابلة:

 Runwith (springJUnit4ClassRunner.Class) contextConfiguration (مواقع = "classpath: /springtest/springockito/testapplicationContext.xml")@ActiveProfiles (phision = {"springtest"}) publicalusterviceiMplproficeImired Autowired Private Bankservice Service ؛ before public void setup () يلقي الاستثناء {mockito.hen (bankservice.getBalanceByEmail ("[email protected]") } test public void should defereReturnMockEdbalance () {double balance = userBalusterervice.getAccountbalance ("[email protected]") ؛ Assertequals (التوازن ، double.valueof (123.45d)) ؛ }}

ربما لاحظت أنه في طريقة الإعداد ، نحدد السلوك المحاكاة ونضيف التعليق التوضيحي profile إلى الفصل. ينشط هذا التعليق التوضيحي ملف تعريف يسمى springtest ، لذلك يمكن حقن الفول المحاكاة باستخدام Springockito تلقائيًا في أي مكان يحتاج إليه. ستكون نتيجة التشغيل لهذا الاختبار ناجحًا لأن Spring يقوم بحقن الإصدار الذي تم محاكاته بواسطة Springockito ، وليس الإصدار المعلن في ApplicationContext.xml.

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

 رمز المصدر لـ userBaluterserViceImPlannotationTest.java: runwith (SpringJunit4ClassRunner.Class) contextConfiguration (loader = springockitocontextloader AUTOWIRED USERBALANCERSERVICE userbalanceservice ؛ @autowired replacewithmock private bankservice service ؛ before public void setup () يلقي استثناء {mockito. when (bankservice.getBalanceByEmail ("[email protected]") } test public void should neantreturnmockedbalance () {double balance = userBalusterervice.getAccountbalance ("[email protected]") ؛ assertequals (الرصيد ، القيمة (123.45D)) ؛ }}

يرجى ملاحظة أنه لا يوجد ملف تكوين XML الذي تم تقديمه حديثًا هنا ، ولكن يتم استخدام ApplicationContext.xml من البيئة الرسمية مباشرة. نستخدم شرح replacewithmock للاحتفال بالفاصوليا من نوع Bankservice ، ثم تحديد سلوك فئة Mock في طريقة الإعداد.

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

رابط الترجمة: http://www.codeceo.com/article/spring-test-is-easy.html
اللغة الإنجليزية الأصلية: اختبرني إذا كنت تستطيع #1 (إطار الربيع)
المترجم: Sandbox Wang ، شبكة الترميز

ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.