क्या मुझे ज्ञात दोषों के लिए यूनिट परीक्षण करना चाहिए?

Question

यदि मेरे कोड में एक ज्ञात खराबी है, जिसे ठीक किया जाना चाहिए, लेकिन अभी तक नहीं है, और वर्तमान रिलीज के लिए तय नहीं किया जाएगा, और भविष्य में तय नहीं किया जा सकता है, तो उस बग के लिए एक असफल इकाई परीक्षण होना चाहिए परीक्षण सूट? यदि मैं इकाई परीक्षण जोड़ता हूं, तो यह (स्पष्ट रूप से) विफल हो जाएगा, और असफल परीक्षण करने की आदत होना एक बुरे विचार की तरह लगता है। दूसरी ओर, अगर यह एक ज्ञात दोष है, और एक ज्ञात विफलता मामला है, तो इसे परीक्षण सूट से बाहर रखना अजीब लगता है, क्योंकि यह कुछ बिंदु पर तय किया जाना चाहिए, और परीक्षण पहले से ही उपलब्ध है।

Comments

मुझे ऐसा नहीं लगता, मैं विशेष रूप से यूनिट टेस्ट

— मार्टिज़न

ज्ञात दोषों के लिए परीक्षणों को प्रतिगमन परीक्षणों के रूप में जाना जाता है , इनका इकाई परीक्षणों से कोई लेना-देना नहीं है ... सटीक होने के लिए, बाद वाला डेवलपर राय पर निर्भर करता है - आपका प्रश्न शायद सभी के बाद डुप्लिकेट नहीं है, बल्कि राय के लिए एक सर्वेक्षण है। यह विशेष रूप से प्रमुख है कि आपने जो उत्तर स्वीकार किया है, वह "यूनिट परीक्षणों" शब्द का उपयोग नहीं करता है, लेकिन इसके बजाय उचित रूप से इन अलग-अलग "ज्ञात विफल परीक्षणों" को कॉल करता है

— gnat

धन्यवाद माइकल, उस पर मदद करता है कैसे JUnit में इस तरह के परीक्षणों को चिह्नित करने के लिए, लेकिन वास्तव में नहीं परीक्षण अभ्यास पर। gnat, मुझे अभी भी समझ नहीं आया है कि आप एक प्रतिगमन परीक्षण के रूप में एक असफल इकाई परीक्षण कैसे देखते हैं। मुझे आपकी टिप्पणियों से एक विशिष्ट शत्रुतापूर्ण निष्क्रिय / आक्रामक वाइब भी मिल रहा है। अगर आपको लगता है कि मुझे अलग तरह से सवाल पूछना चाहिए, तो कृपया ऐसा कहें, क्योंकि अगर आप उन्हें इस तरह से वाक्यांश देते हैं तो मैं आपकी चिंताओं को दूर नहीं कर सकता।

— मार्टिज़न

@gnat: ईमानदारी से, IMHO इससे कोई फर्क नहीं पड़ता कि हम यहाँ परीक्षणों को "इकाई" या "प्रतिगमन" परीक्षण कहते हैं - आपके द्वारा जोड़ा गया प्रश्न भी एक अलग ध्यान केंद्रित करता है, और वहाँ उत्तर यहाँ लागू नहीं होते हैं।

— डॉक ब्राउन

संबंधित: जब उत्पादन में बग पाया जाता है तो क्या मुझे जानबूझकर निर्माण को तोड़ना चाहिए?

— सालस्केक

Answer 1

जवाब है हां, आपको उन्हें लिखना चाहिए और आपको उन्हें चलाना चाहिए।

आपके परीक्षण ढांचे को "ज्ञात विफल परीक्षणों" की एक श्रेणी की आवश्यकता है और आपको इन परीक्षणों को उस श्रेणी में आते हुए चिह्नित करना चाहिए। आप ऐसा कैसे करते हैं, यह फ्रेमवर्क पर निर्भर करता है।

उत्सुकता से, एक असफल परीक्षा जो अचानक पास हो जाती है, केवल उत्तीर्ण परीक्षा के रूप में दिलचस्प हो सकती है जो अप्रत्याशित रूप से विफल हो जाती है।

Comments

पायथन के सबसे अच्छे

— Jace Browning

Answer 2

मुझे लगता है कि आपके पास वर्तमान व्यवहार और टिप्पणियों में एक इकाई परीक्षण होना चाहिए, सही परीक्षण और सही व्यवहार जोड़ें। उदाहरण:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

इस तरह, जब ठीक उपलब्ध है, तो बिल्ड विफल हो जाएगा, आपको असफल परीक्षण को सूचित करता है। जब आप परीक्षण देखेंगे, तो आपको पता चलेगा कि आपने व्यवहार बदल दिया है और परीक्षण को अद्यतन किया जाना चाहिए।

EDIT: जैसा कि कैप्टन मैन ने कहा है, बड़ी परियोजनाओं में, यह जल्द ही कभी भी तय नहीं होगा, लेकिन दस्तावेज के लिए, मूल उत्तर कुछ भी नहीं है।

यह करने के लिए एक बेहतर तरीका है वर्तमान परीक्षा की नकल करना, जिससे क्लोन सही चीज़ का दावा करता है और @Ignoreयह एक संदेश, जैसे

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

यह आपकी टीम के सम्मेलन में @Ignored परीक्षणों की संख्या को कम करने के लिए आता है । बग को प्रतिबिंबित करने के लिए परीक्षण शुरू करने या बदलने के साथ आप उसी तरह से काम करेंगे, जैसे आप अपनी टीम के लिए महत्वपूर्ण होने पर बिल्ड को विफल नहीं करते हैं, जैसे ओपी ने कहा कि बगफिक्स को वर्तमान रिलीज में शामिल नहीं किया जाएगा। ।

Comments

यह बुरी सलाह है। कोई भी इसे ठीक करने का कभी प्रयास नहीं करेगा। लोग केवल पुराने इकाई परीक्षण खोलने जा रहे हैं यदि संकलन मुद्दे या परीक्षण विफल होते हैं।

— कैप्टन मैन

@CaptainMan मैं सहमत हूं, मैंने अपने जवाब को अपडेट किया है ताकि देव टीम को बग के बारे में पता चले बिना बेहतर तरीके से निर्माण को विफल किया जा सके। आपके डाउनवोट को 3 साल पहले पोस्ट किए गए मूल उत्तर के लिए उचित ठहराया गया था, मेरा मानना ​​है कि वर्तमान उत्तर अधिक उपयुक्त है। क्या आप इसे दूसरे तरीके से करेंगे?

— सिल्वियू बर्किया

यह लगभग ऐसा ही है जो मैं उन दुर्लभ अवसरों पर करता हूं जिन्हें मैं बग को अब किसी कारण से ठीक नहीं कर सकता। मुझे यह सुनना अच्छा लगेगा कि आप कैसे स्थिति को संभालते हैं @CaptainMan

— RubberDuck

@ रबरडक वास्तव में यहाँ कोई आदर्श स्थिति नहीं है (बग को ठीक करने के अलावा अब हाहा)। मेरे लिए, कम से कम परीक्षण के परिणाम "10 उत्तीर्ण, 0 असफल, 1 छोड़" को देखकर कम से कम कुछ संकेत है जो कुछ लोगों के लिए परिचित नहीं है। मुझे @Ignoreदृष्टिकोण पसंद है । सिर्फ एक टिप्पणी का उपयोग करने का कारण मेरे लिए एक अच्छा विचार नहीं है क्योंकि मुझे नहीं लगता कि लोग अक्सर उन्हें जांचने के लिए यूनिट परीक्षण खोलेंगे (जब तक कि वे विफल नहीं हो रहे हैं, या (उम्मीद है) जब उन्हें आश्चर्य होता है कि क्यों कुछ को अनदेखा किया जा रहा है )।

— कैप्टन मैन

@ रबरडक वास्तव में यहाँ कोई आदर्श स्थिति नहीं है (बग को ठीक करने के अलावा अब हाहा)। मेरे लिए, कम से कम परीक्षण के परिणाम "10 उत्तीर्ण, 0 असफल, 1 छोड़" को देखकर कम से कम कुछ संकेत है जो कुछ लोगों के लिए परिचित नहीं है। मुझे @Ignoreदृष्टिकोण पसंद है । सिर्फ एक टिप्पणी का उपयोग करने का कारण मेरे लिए एक अच्छा विचार नहीं लगता है क्योंकि मुझे नहीं लगता कि लोग अक्सर उन्हें जांचने के लिए यूनिट परीक्षण खोलेंगे (जब तक कि वे विफल नहीं हो रहे हैं, या (उम्मीद है) जब उन्हें आश्चर्य होता है कि कुछ क्यों छोड़ा जा रहा है )।

— कैप्टन मैन

Answer 3

परीक्षण उपकरण के आधार पर आप omitया pendफ़ंक्शन का उपयोग कर सकते हैं ।

रूबी में उदाहरण:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

omitआदेश एक परीक्षण को छोड़ देता है, omit_ifएक परीक्षण के साथ जोड़ती है यह - मेरी उदाहरण में मैं संस्करण संख्या का परीक्षण करने और केवल संस्करण मैं कहाँ उम्मीद त्रुटि हल किया जाता है के लिए परीक्षण को अंजाम।

मेरे उदाहरण का आउटपुट है:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

तो मेरा जवाब है: हाँ, परीक्षण लागू करें। लेकिन त्रुटियों के साथ एक परीक्षक को भ्रमित न करें, जहां आप जानते हैं कि यह विफल हो जाएगा।

Answer 4

यदि बग आपके दिमाग में ताजा है और आपके पास अभी यूनिट टेस्ट लिखने का समय है, तो मैं इसे अभी लिखूंगा और इसे ज्ञात विफलता के रूप में चिह्नित करूंगा ताकि यह स्वयं को विफल न करे। आपके बग ट्रैकर को यह दर्शाने के लिए अपडेट किया जाना चाहिए कि एक इकाई परीक्षण है जो वर्तमान में इस बग के लिए विफल हो रहा है ताकि व्यक्ति को अंततः इसे ठीक करने के लिए असाइन किया गया हो, यह सब फिर से नहीं लिखता है। इससे यह पता चलता है कि छोटी गाड़ी के कोड को बहुत अधिक रिफैक्टिंग की आवश्यकता नहीं होती है और यह कि एपीआई में काफी बदलाव आता है - अगर ऐसा है तो आप यूनिट टेस्ट को न लिखने से बेहतर हो सकते हैं जब तक आपको इस बात का बेहतर अंदाजा न हो कि टेस्ट कैसे लिखा जाना चाहिए। ।

Answer 5

इसका उत्तर NO IMHO है। आपको बग के लिए एक इकाई परीक्षण नहीं जोड़ना चाहिए जब तक कि आप बग के लिए फिक्स पर काम करना शुरू नहीं करते हैं और जब तक आप बग को साबित नहीं करते हैं, तब तक आप टेस्ट लिखेंगे और बग टेस्ट रिपोर्ट के अनुसार विफल हो रहे हैं ( s) आप जाएंगे और परीक्षण (एस) पास बनाने के लिए वास्तविक कोड को सही करेंगे और बग को हल किया जाएगा और इसके बाद इसे कवर किया जाएगा।

मेरी दुनिया में हमारे पास एक मैनुअल टेस्ट केस होगा जो कि बग तय होने तक QEs फेल रहा है। और डेवलपर्स के रूप में हमें इसकी जानकारी मैनुअल फेलिंग टीसी के माध्यम से और बग ट्रैकर के माध्यम से होगी।

यूटी को फेल नहीं करने का कारण सरल है। UT प्रत्यक्ष प्रतिक्रिया के लिए हैं और एक डेवलपर के रूप में मैं वर्तमान में काम कर रहा हूं। और UT सिस्टम का उपयोग CI सिस्टम में किया जाता है ताकि यह सुनिश्चित हो सके कि मैं उस मॉड्यूल के कोड के किसी अन्य क्षेत्र में अनजाने में कुछ तोड़ नहीं रहा हूं। जान बूझकर आईएमएचओ के लिए जानबूझकर असफल होने के कारण, यूटीएचए काउंटर उत्पादक और सिर्फ सादा गलत होगा।

Answer 6

मुझे लगता है कि उत्तर वास्तव में है, यह निर्भर करता है। इसके बारे में व्यावहारिक रहें। अब इसे लिखने से आपको क्या हासिल होता है? शायद यह आपके दिमाग में ताजा है?

बग को ठीक करते समय, यह साबित करता है कि बग को उजागर करने वाली इकाई परीक्षण लिखकर यह साबित होता है। फिर आप बग को ठीक करते हैं, और यूनिट टेस्ट पास करना चाहिए।

क्या आपके पास अभी असफल इकाई परीक्षण लिखने का समय है? क्या अधिक दबाने वाले फ़ीचर या बग हैं जिन्हें लिखने / तय करने की आवश्यकता है।

मान लें कि आप बग यह में लॉग इन के साथ सक्षम बग ट्रैकिंग सॉफ्टवेयर है, वहाँ वास्तव में नाकाम रहने इकाई परीक्षण लिखने के लिए कोई जरूरत नहीं है अभी ।

यदि आप बग फिक्स के बिना हो रहा है एक रिलीज से पहले एक असफल इकाई परीक्षण शुरू करते हैं तो संभवतः आप कुछ भ्रम का परिचय दे सकते हैं।

Answer 7

मैं आमतौर पर परीक्षण सूट में ज्ञात विफलताओं के बारे में असहज महसूस करता हूं, क्योंकि यह समय के साथ सूची में बढ़ने के लिए, या समान परीक्षणों में असंबद्ध विफलताओं के लिए "अपेक्षित" के रूप में खारिज करने के लिए बहुत आसान है। समान चीजें आंतरायिक विफलताओं के लिए जाती हैं - कोड को गुप्त रखने वाली कुछ बुराई हो सकती है। मैं कोड के लिए परीक्षण लिखने के लिए मतदान करूंगा क्योंकि यह अब है, और जैसा कि इसे एक बार तय किया जाना चाहिए, लेकिन किसी भी तरह टिप्पणी की गई या निष्क्रिय कर दी गई।