জুনিট পরীক্ষার ক্ষেত্রে 'ব্যর্থ' এর আসল ব্যবহার কী?

Question

জুনিট পরীক্ষার ক্ষেত্রে 'ব্যর্থ' এর আসল ব্যবহার কী?

Answer 1

কিছু ক্ষেত্রে যেখানে আমি এটি দরকারী পেয়েছি:

• অসম্পূর্ণ একটি পরীক্ষা চিহ্নিত করুন, যাতে এটি ব্যর্থ হয় এবং আপনি এটি শেষ না করা পর্যন্ত আপনাকে সতর্ক করে দেয়
• একটি ব্যতিক্রম নিক্ষেপ করা হয়েছে তা নিশ্চিত করে:

try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

বিঃদ্রঃ:

JUnit4 যেহেতু, একটি ব্যতিক্রম ছোঁড়া হচ্ছে তা পরীক্ষা করার আরও একটি মার্জিত উপায় রয়েছে: টীকাটি ব্যবহার করুন @Test(expected=IndexOutOfBoundsException.class)

যাইহোক, এই না করবে না কাজ করেন তাহলে আপনি ব্যতিক্রম পরিদর্শন করতে চান, তাহলে আপনি এখনও প্রয়োজন fail()।

Comments

ব্যর্থ ও বনাম প্রত্যাশিত টীকা সম্পর্কিত আপেক্ষিক গুণাগুণ সম্পর্কে এই ব্লগ পোস্টটি বিবেচনা করুন: blog.jooq.org/2016/01/20/…

— lbalazscs

@ স্লেসকে "যদি আপনিও ব্যতিক্রমটি পরিদর্শন করতে চান তবে আপনার এখনও ব্যর্থ ()" দরকার - না। প্রত্যাশিতই ধারণাটি

— জুন

@ ক্র্যাকসর: সত্য, আমি যখন উত্তরটি লিখি তখন এটি সম্পর্কে জানতাম না (এটি সম্ভবত তখনও ছিল না)।

— sleske

Answer 2

যাক আপনি একটি প্রবাহের জন্য একটি পরীক্ষার কেস লিখছেন যেখানে পরীক্ষা করা কোডটি একটি ব্যতিক্রম বাড়াতে হবে

try{
   bizMethod(badData);
   fail(); // FAIL when no exception is thrown
} catch (BizException e) {
   assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
}

Answer 3

আমি মনে করি স্বাভাবিক ব্যবহারের ক্ষেত্রে এটি কল করা যখন কোনও নেতিবাচক পরীক্ষায় ব্যতিক্রম হয় নি।

নিম্নলিখিত সিউডো-কোডের মতো কিছু:

test_addNilThrowsNullPointerException()
{
    try {
        foo.add(NIL);                      // we expect a NullPointerException here
        fail("No NullPointerException");   // cause the test to fail if we reach this            
     } catch (NullNullPointerException e) {
        // OK got the expected exception
    }
}

Comments

আপনি যদি ক্যাচ ব্লকে কিছু পরীক্ষা না করে থাকেন তবে আপনি অপ্রত্যাশিত (একটি বিশেষ ধরণের) প্রত্যাশার জন্য @ অপ্রত্যাশিত এক্সপশন (নুলনুলপয়েন্টারএক্সেপশন.ক্লাস) পদ্ধতির টীকাটি ব্যবহার করতে পারেন।

— FrVaBe

Answer 4

আমার @ পূর্ব পদ্ধতিতে এমন কিছু ঘটতে পারে যেখানে এমন কিছু ঘটেছে I've

public Object obj;

@Before
public void setUp() {
    // Do some set up
    obj = new Object();
}

@Test
public void testObjectManipulation() {
    if(obj == null) {
        fail("obj should not be null");
     }

    // Do some other valuable testing
}

Comments

হ্যাঁ, পূর্বশর্ত পরীক্ষা করা ভাল। তবে আপনি যদি @Beforeপদ্ধতিটি সফল হয়েছে তা নিশ্চিত করতে চান তবে সম্ভবত সরাসরি সেই পদ্ধতিতে এটি পরীক্ষা করা ভাল। একটি বোনাস হিসাবে, কমপক্ষে JUnit এবং TestNG এমনকি @Before/ @Afterপদ্ধতিগুলির ত্রুটিগুলির জন্য পৃথক ব্যর্থতারও রিপোর্ট করবে , সুতরাং দেখতে পাবে যে সমস্যাটি নিজেই পরীক্ষায় ছিল না।

— সলেসকে

Answer 5

এইভাবে আমি ফেল পদ্ধতিটি ব্যবহার করি।

তিনটি রাজ্য রয়েছে যে আপনার পরীক্ষার কেস শেষ হতে পারে

1. উত্তীর্ণ: পরীক্ষার অধীনে ফাংশনটি সাফল্যের সাথে কার্যকর করা হয়েছিল এবং প্রত্যাশার মতো ডেটা ফেরত দেয়
2. উত্তীর্ণ হয়নি: পরীক্ষার অধীনে ফাংশনটি সাফল্যের সাথে কার্যকর হয়েছে তবে প্রত্যাশিত ডেটা প্রত্যাশার মতো ছিল না
3. ব্যর্থ: ফাংশনটি সফলভাবে সম্পাদিত হয়নি এবং এটিও হয়নি

উদ্দেশ্যযুক্ত (নেতিবাচক পরীক্ষার মামলার মতো যা ব্যতিক্রম হওয়ার প্রত্যাশা করে)।

আপনি যদি সেখানে গ্রহনটি ব্যবহার করছেন তবে তিনটি রাজ্য যথাক্রমে সবুজ, নীল এবং লাল চিহ্নিতকারী দ্বারা নির্দেশিত।

আমি তৃতীয় দৃশ্যের জন্য ব্যর্থ অপারেশনটি ব্যবহার করি।

উদাহরণস্বরূপ: সর্বজনীন পূর্ণসংখ্যার যোগ (পূর্ণসংখ্যা ক, পূর্ণসংখ্যা খ) new নতুন পূর্ণসংখ্যা (a.intValue () + বি.আইনটিভ্যালু ()) ফেরান}

1. উত্তীর্ণ কেস: a = নতুন পূর্ণসংখ্যা (1), খ = নতুন পূর্ণসংখ্যা (2) এবং ফাংশনটি 3 এ ফিরে এসেছে
2. পাস করা হয়নি কেস: এ = নতুন ইন্টার্জার (1), বি = নতুন পূর্ণসংখ্যা (2) এবং ফাংশনটি 3 ব্যতীত সোমের মান প্রদান করেছে
3. ব্যর্থ কেস: এ = নাল, বি = নাল এবং ফাংশনটি নুলপয়েন্টার এক্সসেপশন নিক্ষেপ করে

Comments

আপনি যদি JUnit এর উত্স কোডটি লক্ষ্য করেন তবে আপনি দেখতে পাবেন যে সংবিধানগুলি ব্যবহার করা হচ্ছে fail()।

— ড্যানিয়েল সি সোব্রাল

Answer 6

আমি উদাহরণস্বরূপ, fail()পরীক্ষা শেষ করে এখনও শেষ হয়নি (এটি ঘটে) নির্দেশ করতে ব্যবহার করি; অন্যথায়, তারা সফল হিসাবে প্রদর্শিত হবে।

এটি সম্ভবত এই কারণে যে আমি কোনও ধরণের অসম্পূর্ণ () কার্যকারিতা সম্পর্কে অজ্ঞাত যা নুনিটে বিদ্যমান।

Answer 7

সমবর্তী এবং / অথবা অ্যাসিঙ্ক্রোনাস সেটিংস, আপনি যে নির্দিষ্ট পদ্ধতি যাচাই করতে চান পারে (যেমন প্রতিনিধিদের, ঘটনা শ্রোতাকে, প্রতিক্রিয়া হ্যান্ডেলার, আপনি এটির নাম হয় না) না বলা হয়। ফ্রেমওয়ার্ককে উপহাস করে, আপনি fail()পরীক্ষাগুলিতে ব্যর্থ হওয়ার জন্য সেই পদ্ধতিগুলিতে কল করতে পারেন । মেয়াদ উত্তীর্ণ সময়সীমা এই জাতীয় পরিস্থিতিতে একটি প্রাকৃতিক ব্যর্থতা শর্ত।

উদাহরণ স্বরূপ:

final CountDownLatch latch = new CountDownLatch(1);

service.asyncCall(someParameter, new ResponseHandler<SomeType>() {
    @Override
    public void onSuccess(SomeType result) {
        assertNotNull(result);
        // Further test assertions on the result
        latch.countDown();
    }

    @Override
    public void onError(Exception e) {
        fail(exception.getMessage());
        latch.countDown();
    }
});

if ( !latch.await(5, TimeUnit.SECONDS) ) {
    fail("No response after 5s");
}

Answer 8

সর্বাধিক গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে সম্ভবত ব্যতিক্রম পরীক্ষা করা।

যদিও জুনিট 4 কোনও ব্যতিক্রম ঘটেছে কিনা তা যাচাই করার জন্য প্রত্যাশিত উপাদানটি অন্তর্ভুক্ত করে , মনে হয় এটি নতুন জুনিট 5 এর অংশ নয়। fail()ওভার ব্যবহার করার আরেকটি সুবিধা expectedহ'ল আপনি এটিকে finallyটেস্ট-কেস ক্লিনআপের অনুমতি দিয়ে একত্রিত করতে পারেন ।

dao.insert(obj);
try {
  dao.insert(obj);
  fail("No DuplicateKeyException thrown.");
} catch (DuplicateKeyException e) {
  assertEquals("Error code doesn't match", 123, e.getErrorCode());
} finally {
  //cleanup
  dao.delete(obj);
}

যেমনটি অন্য একটি মন্তব্যে উল্লিখিত হয়েছে। আপনি প্রয়োগটি শেষ না করা পর্যন্ত ব্যর্থ হওয়ার জন্য একটি পরীক্ষা করা যুক্তিসঙ্গত বলে মনে হয়।