دليل لاستخدام Junit ، إطار اختبار الاستثناء في Java

Junit هو إطار اختبار الانحدار الذي كتبه Erich Gamma و Kent Beck. اختبار Junit هو اختبار المبرمج ، أي اختبار الصندوق الأبيض. الصفحة الرئيسية للمشروع: http://www.junit.org/

عند استخدام JUNIT ، يمكنك كتابة حالات الاختبار بشكل أساسي عن طريق وراثة فئة TestCase ، واستخدم اسم Testxxx () لكتابة اختبارات الوحدة.

هناك ثلاثة أشياء تحتاج حقًا إلى كتابة اختبارات مع Junit:

1. بيان الاستيراد يقدم جميع الفصول تحت junit.framework.*.

2. يتيح بيان تمديد فصلك أن يرث من testcase.

3. مُنشئ يدعو Super (سلسلة).

MathTool الوظيفية

 package com.zj.c01 ؛ public class mathtool {public static int gcd (int num1 ، int num2) {int r = 0 ؛ بينما (num2! = 0) {r = num1 ٪ num2 ؛ num1 = num2 ؛ num2 = r ؛ } إرجاع num1 ؛ }}

اختبار فئة MathTooltest

 حزمة com.zj.c01 ؛ import junit.framework.testcase ؛ الطبقة العامة MathToolTest يمتد testcase {public MathToolTest (اسم السلسلة) {super (name) ؛ } public void testgcd () {assertequals (5 ، mathtool.gcd (10 ، 5)) ؛ }}

عندما نستخدم Junit لاختبار الاستثناءات ، فإن أسهل طريقة للتفكير هي استخدام المحاولة ... Catch للقبض على الاستثناء. نحن بحاجة إلى تأكيد الشروط التالية:
1. استثناء تم طرحه بالفعل 2. نوع فئة الاستثناء الذي تم إلقاؤه 3. يتم طرح النوع المحدد من الاستثناء. بشكل عام ، تحقق من تحديد السلسلة الواردة في سمة الرسالة للاستثناء. لذلك يمكنك كتابة الرمز الشائع مثل هذا:

 test public void testBizexception () {try {password.validate ("123") ؛ فشل ("لم يتم إلقاء استثناء.") ؛ } catch (استثناء ex) {assertTrue (ex extreamof bizexception) ؛ AssertTrue (ex.getMessage (). يحتوي على ("خطأ")) ؛ }}

الطريقة التي تم اختبارها هنا هي ما إذا كانت طريقة password.validate () ترمي الاستثناء المقابل. يرجى ملاحظة أن الفشل ("لم يتم إلقاء استثناء.") في المحاولة لا يتم تفويتها هنا.
سطر التعليمات البرمجية ، وإلا إذا كانت الطريقة التي يتم اختبارها لا ترمي استثناءً ، فستمر حالة الاستخدام هذه ، وما تتوقعه هو إلقاء استثناء.
في Junit 4 ، ليست هناك حاجة لاختبار استثناءات طريقة مثل هذا. على الرغم من أن هذا يمكن أن يحدد أيضًا ما إذا كان يتم تنفيذ الاستثناء المتوقع ، إلا أنه لا يزال لديه عيوب. ستعرف بعد مقارنتها. لا يمكن أن يوضح لك Junit السبب التفصيلي لفشل التأكيد في المحاولة ... طريقة الصيد.
لذلك دعونا نلقي نظرة على كيفية اختبار الاستثناءات منذ Junit 4؟ ما عليك سوى استخدام @test (envpted = insception.class) ، يرجى الرجوع إلى الكود التالي:

 test (متوقع = bizexception.class) public void testBizexception () {password.validate (null) ؛ }

إذا كانت الطريقة التي يتم اختبارها لها نوع bizexception ، فإن التأكيد ناجح. بالمناسبة ، يمكن لـ test (المتوقع = bizexception.class) تحديد نوع الاستثناء فقط ، ولا يوجد أي شرح مماثل لتأكيد المزيد من المعلومات المحددة حول الاستثناء ، أي أنه لا يمكن تحديد سمة الرسالة للاستثناء الذي تم إلقاؤه.
بعد ذلك ، في بعض الأحيان ، سنقوم باستثناء نوع واحد عدة مرات بطريقة ما ، ولكن الأسباب مختلفة ، أي معلومات رسالة الاستثناء مختلفة. على سبيل المثال ، عند حدوث Bizexception ، سيكون هناك استثناءان التاليان:

 Bizexception جديد ("يجب أن تحتوي كلمة المرور على 6 أحرف على الأقل.") Bizexception جديد ("طول كلمة المرور أقل من 15 حرفًا")

هذا يتطلب طريقة لتأكيد رسالة الاستثناء. لهذا السبب ، منذ Junit 4.7 ، قدمنا ​​خيارًا أكثر مثالية ، وهو الرمز التالي:

 @Rule public equiredException equiredex = equiredException.none () ؛ Test public void testBizexception () يلقي invalidPasswordException {equirectex.expect (bizexception.class) ؛ متوقع. ExpectMessage ("مطلوب") ؛ password.validate ("") ؛ }

الرمز أعلاه يجب أن يركز على:
1. roule reprentated reconted repication reportation ، يجب أن يكون علنيًا
2. في test ، لا يمكن كتابته كـ test (متوقع = bizexception.class) ، وإلا لا يمكن اختباره بشكل صحيح. وهذا هو ، test (متوقع = bizexception.class) وطريقة متوقعة. 3. المعلمات في المتوقع. 4. شيء آخر هو ثقيل للغاية ، اكتب الطريقة التي تم اختبارها خلف طريقة متوقعة. Expectxxx () ، وإلا فإن الاستثناء الذي لا يمكن اختباره بشكل صحيح 5. آخر ما طالما أن طريقة الاختبار ترمي مباشرة استثناء الطريقة التي يتم اختبارها ، فلن يؤثر ذلك على الاستثناء الذي تشعر بالقلق بشأنه. كما ذكرنا سابقًا ، يمكن أن يؤدي استخدام طريقة Catch ... إلى اختبار الاستثناء بشكل صحيح. ما هي فوائد مقارنة test (متوقعة = ...) أو raule وحاول ... طريقة الصيد؟ من الواضح أن الطريقة الموصى بها من قبل Junit 4 موجزة وواضحة. دعونا نلقي نظرة على ما الذي سيطالبك Junit عندما يفشل الاختبار؟
المطالبة التي تحصل عليها عندما فشل الاختبار بشكل غير طبيعي:
عندما لا يكون هناك استثناء:

 java.lang.assertionerror: لا استثناء. في org.junit.assert.fail (assert.java:91) في cc.unmi.passwordtest.passwordlhulshann6lettersthrowsexception (passwordtest.java:20)

عندما يكون نوع الاستثناء خطأ أو أن رسالة الاستثناء خاطئة:

 java.lang.assertionerror: at org.junit.assert.fail (Assert.java:91) at org.junit.assert.asserttrue (assert.java:43) at org.junit.asserttrue (assert.java:54) at cc.unmi.passwordtest.passwordlhulsthan6lettersthrowSexception (passwordtest.java:22)

المساعدة أعلاه لأخطاء تحديد المواقع ليست رائعة بشكل خاص. انظر إلى المطالبات عندما يفشل الاختبار عند @test (متوقع = bizexception.class):

 java.lang.assertionerror: الاستثناء المتوقع: cc.test.bizexception at org.junit.internal.runners.statements.expectexception.evaluate (TepresseException.java:32) في org.junit.rules.expectectionexception.

استخدم @Rules Entermexception لاختبار الاستثناءات. نصائح عند الفشل:

 java.lang.assertionerror: متوقع: (استثناء مع رسالة سلسلة تحتوي على "نعم. مطلوب" ومثال على java.lang.nullpointerexception): على org.junit.assert.assertthat (assert.java:778) في org.junit.assert.assertthat (Assert.java:736) at org.junit.rules.expectedException $ المتوقع exception.evaltuer (المتوقع exception.java:114)

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