Erlang 21 - 5. Writing Test Suites

5 लेखन टेस्ट सूट




erlang

5 लेखन टेस्ट सूट

5.1 टेस्ट सूट लेखकों के लिए समर्थन

ct मॉड्यूल परीक्षण मामलों को लिखने के लिए मुख्य इंटरफ़ेस प्रदान करता है। इसमें उदाहरण के लिए, निम्नलिखित शामिल हैं:

  • मुद्रण और लॉगिंग के लिए कार्य
  • कॉन्फ़िगरेशन डेटा पढ़ने के लिए कार्य
  • त्रुटि के कारण के साथ परीक्षण मामले को समाप्त करने का कार्य
  • HTML अवलोकन पृष्ठ पर टिप्पणी जोड़ने का कार्य

इन कार्यों के बारे में जानकारी के लिए, मॉड्यूल ct देखें।

Common Test एप्लिकेशन में ct_<component> नाम के अन्य मॉड्यूल भी शामिल हैं, जो विभिन्न समर्थन प्रदान करते हैं, मुख्य रूप से संचार प्रोटोकॉल जैसे कि आरपीसी, एसएनएमपी, एफटीपी, टेलनेट और अन्य।

5.2 टेस्ट सूट

एक परीक्षण सूट एक साधारण एर्लांग मॉड्यूल है जिसमें परीक्षण मामले होते हैं। यह अनुशंसा की जाती है कि मॉड्यूल का फॉर्म *_SUITE.erl पर एक नाम हो। अन्यथा, Common Test में निर्देशिका और ऑटो संकलन समारोह इसे नहीं ढूँढ सकता (कम से कम डिफ़ॉल्ट रूप से नहीं)।

यह भी अनुशंसा की जाती है कि ct.hrl हैडर फ़ाइल सभी परीक्षण सूट मॉड्यूल में शामिल है।

प्रत्येक परीक्षण सूट मॉड्यूल को all/0 फ़ंक्शन को निर्यात करना चाहिए, जो उस मॉड्यूल में निष्पादित किए जाने वाले सभी परीक्षण केस समूहों और परीक्षण मामलों की सूची लौटाता है।

परीक्षण सूट द्वारा लागू किए जाने वाले कॉलबैक फ़ंक्शन सभी को सामान्य common_test में सूचीबद्ध किए गए हैं। उन्हें बाद में इस उपयोगकर्ता की मार्गदर्शिका में और अधिक विस्तार से वर्णित किया गया है।

५.३ इंच और अंत प्रति सूट

प्रत्येक परीक्षण सूट मॉड्यूल में वैकल्पिक कॉन्फ़िगरेशन फ़ंक्शन init_per_suite/1 और end_per_suite/1 । यदि init फ़ंक्शन परिभाषित है, तो अंतिम फ़ंक्शन होना चाहिए।

यदि init_per_suite मौजूद है, तो परीक्षण के मामलों को निष्पादित करने से पहले इसे शुरू में कहा जाता है। इसमें आम तौर पर सुइट में सभी परीक्षण मामलों के लिए इनिशियलाइज़ेशन कॉमन होते हैं, जो केवल एक बार किए जाते हैं। init_per_suite को सिस्टम अंडर टेस्ट (SUT) या Common Test होस्ट नोड, या दोनों पर राज्य और पर्यावरण को स्थापित करने और सत्यापित करने के लिए अनुशंसित किया जाता है, ताकि सूट में परीक्षण के मामले सही तरीके से निष्पादित हों। निम्नलिखित प्रारंभिक कॉन्फ़िगरेशन ऑपरेशन के उदाहरण हैं:

  • SUT के लिए एक कनेक्शन खोलना
  • डेटाबेस को प्रारंभ करना
  • एक इंस्टॉलेशन स्क्रिप्ट चलाना

end_per_suite को परीक्षण सूट निष्पादन के अंतिम चरण के रूप में कहा जाता है (अंतिम परीक्षण के बाद मामला समाप्त हो गया है)। फ़ंक्शन का उपयोग init_per_suite बाद सफाई के लिए किया जाता है।

init_per_suite और end_per_suite समर्पित Erlang प्रक्रियाओं पर अमल करते हैं, जैसे परीक्षण मामले करते हैं। इन कार्यों का परिणाम हालांकि सफल, असफल और छोड़े गए मामलों के परीक्षण रन आंकड़ों में शामिल नहीं है।

init_per_suite का तर्क Config , अर्थात रनटाइम कॉन्फ़िगरेशन डेटा की समान कुंजी-मूल्य सूची जो प्रत्येक परीक्षण केस इनपुट तर्क के रूप में लेता है। init_per_suite इस पैरामीटर को उन सूचनाओं के साथ संशोधित कर सकता है जिनकी परीक्षण मामलों को आवश्यकता होती है। संभवतः संशोधित Config सूची फ़ंक्शन का रिटर्न मान है।

यदि init_per_suite विफल रहता है, तो परीक्षण सूट में सभी परीक्षण मामले स्वतः init_per_suite हो जाते हैं (तथाकथित ऑटो end_per_suite ), जिसमें end_per_suite

ध्यान दें कि यदि init_per_suite और end_per_suite सुइट में मौजूद नहीं हैं, तो Common Test डमी फ़ंक्शंस (समान नामों के साथ) के बजाय कॉल करता है, ताकि हुक फ़ंक्शंस द्वारा उत्पन्न आउटपुट को इन डमीज़ के लिए लॉग फ़ाइलों में सहेजा जा सके। विवरण के लिए, Common Test Hooks देखें।

5.4 प्रति परीक्षण प्रकरण और अंत

प्रत्येक परीक्षण सूट मॉड्यूल में वैकल्पिक कॉन्फ़िगरेशन फ़ंक्शन init_per_testcase/2 और end_per_testcase/2 । यदि init फ़ंक्शन परिभाषित है, तो अंतिम फ़ंक्शन होना चाहिए।

यदि init_per_testcase मौजूद है, तो इसे सुइट में प्रत्येक परीक्षण मामले से पहले कहा जाता है। इसमें आमतौर पर आरंभीकरण होता है जो प्रत्येक परीक्षण मामले (सुइट के लिए init_per_suite अनुरूप) के लिए किया जाना चाहिए।

end_per_testcase/2 को प्रत्येक परीक्षण केस समाप्त होने के बाद कहा जाता है, init_per_testcase बाद सफाई को सक्षम init_per_testcase

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

दूसरा तर्क रनटाइम कॉन्फ़िगरेशन डेटा की Config की-वैल्यू लिस्ट है, जिसमें init_per_suite द्वारा init_per_suite गई लिस्ट की तरह ही वैल्यू है। init_per_testcase/2 इस पैरामीटर को संशोधित कर सकता है या इसे "जैसा है" वापस कर सकता है। init_per_testcase/2 का रिटर्न मान पैरामीटर के रूप में परीक्षण मामले में Config किया गया है।

end_per_testcase/2 रिटर्न वैल्यू को टेस्ट सर्वर द्वारा save_config और fail tuple के साथ अनदेखा किया जाता है।

यदि परीक्षण का मामला सफल था, तो end_per_testcase जाँच कर सकता है। (जो बदले में यह निर्धारित कर सकता है कि सफाई कैसे करनी है)। यह Config से tc_status साथ टैग किए गए मान को पढ़कर किया जाता है। मान निम्न में से एक है:

  • ok

  • {failed,Reason}

    जहां Reason समय- timetrap_timeout , exit/1 जानकारी exit/1 , या एक रनटाइम त्रुटि का विवरण

  • {skipped,Reason}

    जहां Reason एक उपयोगकर्ता-विशिष्ट शब्द है

फ़ंक्शन end_per_testcase/2 को तब भी कहा जाता है, जब ct:abort_current_testcase/1 कॉल करने के कारण या समय-समय पर आउट होने के बाद कोई परीक्षण केस समाप्त हो जाता है। हालाँकि, end_per_testcase तब परीक्षण केस फ़ंक्शन की तुलना में एक अलग प्रक्रिया पर end_per_testcase करता है। इस स्थिति में, end_per_testcase {fail,Reason} को वापस करके या {save_config,Data} साथ डेटा सहेज कर टेस्ट केस समाप्ति का कारण नहीं बदल सकता है।

परीक्षण मामले को निम्नलिखित दो मामलों में छोड़ दिया गया है:

  • अगर init_per_testcase क्रैश हो जाता है (जिसे ऑटो init_per_testcase कहा जाता है)।
  • यदि init_per_testcase एक tuple {skip,Reason} init_per_testcase {skip,Reason} (जिसे यूजर init_per_testcase कहा जाता है) लौटाता है।

परीक्षण मामले को init_per_testcase {fail,Reason} को init_per_testcase से वापस करके इसे निष्पादित किए बिना विफल के रूप में चिह्नित किया जा सकता है।

ध्यान दें

यदि init_per_testcase क्रैश हो जाता है, या {skip,Reason} init_per_testcase {skip,Reason} या {fail,Reason} end_per_testcase है, तो फंक्शन end_per_testcase नहीं कहा जाता है।

यदि यह end_per_testcase निष्पादन के दौरान निर्धारित किया जाता है कि एक सफल परीक्षण मामले की स्थिति को विफल करने के लिए परिवर्तित किया जाना है, तो end_per_testcase tuple {fail,Reason} (जहाँ Reason बताता है कि परीक्षण केस विफल क्यों होता है) वापस कर सकता है।

जैसा कि init_per_testcase और end_per_testcase एक ही Erlang प्रक्रिया पर परीक्षण केस के रूप में निष्पादित करते हैं, इन कॉन्फ़िगरेशन फ़ंक्शन से प्रिंटआउट को टेस्ट केस लॉग फ़ाइल में शामिल किया जाता है।

5.5 टेस्ट केस

परीक्षण सर्वर के साथ संबंध रखने वाली सबसे छोटी इकाई एक परीक्षण मामला है। प्रत्येक परीक्षण का मामला कई चीजों का परीक्षण कर सकता है, उदाहरण के लिए, विभिन्न मापदंडों के साथ एक ही इंटरफ़ेस फ़ंक्शन के लिए कई कॉल करें।

लेखक प्रत्येक परीक्षण मामले में कई या कुछ परीक्षण करने का विकल्प चुन सकता है। ध्यान रखने योग्य कुछ बातें इस प्रकार हैं:

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

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

  • जब परीक्षण के मामले बहुत बड़े और व्यापक हो जाते हैं तो पठनीयता और स्थिरता बनी रहती है। यह निश्चित नहीं है कि परिणामी लॉग फाइलें बहुत अच्छी तरह से प्रदर्शित परीक्षणों की संख्या को दर्शाती हैं।

परीक्षण केस फ़ंक्शन एक तर्क लेता है, Config , जिसमें कॉन्फ़िगरेशन जानकारी जैसे data_dir और priv_dir । (इनके बारे में विवरण के लिए, अनुभाग Data and Private Directories । कॉल के समय Config मान, init_per_testcase से वापसी मान के init_per_testcase , जिसका उल्लेख पहले किया गया था।

ध्यान दें

परीक्षण मामला फ़ंक्शन तर्क Config कॉन्फ़िगरेशन फ़ाइलों से पुनर्प्राप्त की जा सकने वाली जानकारी ( ct:get_config/1/2 का उपयोग करके) के साथ भ्रमित नहीं होना है। परीक्षण मामले का तर्क Config का उपयोग परीक्षण सूट के रनटाइम कॉन्फ़िगरेशन और परीक्षण मामलों के लिए किया जाना है, जबकि कॉन्फ़िगरेशन फ़ाइलों में SUT से संबंधित डेटा शामिल हैं। इन दो प्रकार के कॉन्फ़िगरेशन डेटा को अलग-अलग तरीके से हैंडल किया जाता है।

जैसा कि पैरामीटर Config कुंजी-मूल्य ट्यूपल्स की एक सूची है, अर्थात, एक डेटा प्रकार जिसे एक संपत्ति सूची कहा जाता है, इसे proplists मॉड्यूल द्वारा नियंत्रित किया जा सकता है। एक मूल्य, उदाहरण के लिए, खोजा जा सकता है और फ़ंक्शन proplists:get_value/2 साथ लौटाया जा सकता है proplists:get_value/2 । इसके अलावा, या वैकल्पिक रूप से, सामान्य lists मॉड्यूल में उपयोगी कार्य शामिल हैं। आम तौर पर, Config पर किया जाने वाला एकमात्र ऑपरेशन सम्मिलित होता है (सूची के प्रमुख पर टपल जोड़कर) और लुकअप। Common Test नाम दिया गया एक सरल मैक्रो प्रदान करता है; जो कि दिए गए Config में एक आइटम का मूल्य देता है (बिल्कुल proplists:get_value तरह proplists:get_value )। उदाहरण: PrivDir = ?config(priv_dir, Config)

यदि परीक्षण केस फ़ंक्शन क्रैश हो जाता है या जानबूझकर बाहर निकल जाता है, तो इसे विफल माना जाता है। यदि यह कोई मान देता है (चाहे कोई भी मूल्य हो), इसे सफल माना जाता है। इस नियम का अपवाद रिटर्न मान {skip,Reason} । यदि यह टपल लौटाया जाता है, तो परीक्षण मामले को छोड़ दिया जाता है और इस तरह लॉग किया जाता है।

यदि परीक्षण मामला टपल {comment,Comment} , तो मामला सफल माना जाता है और Comment अवलोकन लॉग फ़ाइल में मुद्रित होती है। यह कॉलिंग ct:comment(Comment) बराबर है।

5.6 परीक्षण मामले की जानकारी समारोह

प्रत्येक परीक्षण केस फ़ंक्शन के लिए एक ही नाम के साथ एक अतिरिक्त फ़ंक्शन हो सकता है लेकिन बिना तर्क के। यह टेस्ट केस इंफॉर्मेशन फंक्शन है। यह टैग किए गए टुपल्स की सूची वापस करने की उम्मीद है जो परीक्षण के मामले के बारे में विभिन्न गुणों को निर्दिष्ट करता है।

निम्नलिखित टैग का विशेष अर्थ है:

timetrap

अधिकतम समय सेट करता है जब परीक्षण मामले को निष्पादित करने की अनुमति दी जाती है। यदि यह समय अधिक हो जाता है, तो परीक्षण का मामला समय- timetrap_timeout साथ विफल हो जाता है। ध्यान दें कि init_per_testcase और end_per_testcase समयावधि के समय में शामिल हैं। विवरण के लिए, अनुभाग Timetrap Time-Outs देखें।

userdata

परीक्षण मामले से संबंधित किसी भी डेटा को निर्दिष्ट करता है। यह डेटा किसी भी समय ct:userdata/3 यूटिलिटी फ़ंक्शन का उपयोग करके पुनर्प्राप्त किया जा सकता है।

silent_connections

विवरण के लिए, अनुभाग Silent Connections देखें।

require

परीक्षण मामले के लिए आवश्यक कॉन्फ़िगरेशन चर निर्दिष्ट करता है। यदि आवश्यक कॉन्फ़िगरेशन चर परीक्षण सिस्टम कॉन्फ़िगरेशन फ़ाइलों में से किसी में नहीं पाए जाते हैं, तो परीक्षण केस छोड़ दिया जाता है।

यदि किसी कॉन्फ़िगरेशन फ़ाइल में चर नहीं पाया जाता है, तो एक आवश्यक चर को एक डिफ़ॉल्ट मान भी दिया जा सकता है। डिफ़ॉल्ट मान निर्दिष्ट करने के लिए, परीक्षण मामले की जानकारी सूची (सूची में स्थिति अप्रासंगिक) के रूप में {default_config,ConfigVariableName,Value} पर एक टपल जोड़ें।

उदाहरण:

testcase1() -> 
    [{require, ftp},
     {default_config, ftp, [{ftp, "my_ftp_host"},
                            {username, "aladdin"},
                            {password, "sesame"}]}}].
testcase2() -> 
    [{require, unix_telnet, unix},
     {require, {unix, [telnet, username, password]}},
     {default_config, unix, [{telnet, "my_telnet_host"},
                             {username, "aladdin"},
                             {password, "sesame"}]}}].

require बारे में अधिक जानकारी के require , अनुभाग को देखना require Requiring and Reading Configuration Data बाहरी कॉन्फ़िगरेशन डेटा और फ़ंक्शन ct:require/1/2

ध्यान दें

एक आवश्यक चर के लिए एक डिफ़ॉल्ट मान निर्दिष्ट करने के परिणामस्वरूप एक परीक्षण मामला हमेशा निष्पादित हो सकता है। यह एक वांछित व्यवहार नहीं हो सकता है।

यदि समय- timetrap या require , या दोनों, किसी विशेष परीक्षण मामले के लिए विशेष रूप से सेट नहीं है, तो फ़ंक्शन suite/0 द्वारा निर्दिष्ट डिफ़ॉल्ट मान का उपयोग किया जाता है।

पहले बताए गए टैग के अलावा अन्य परीक्षण सर्वर द्वारा नजरअंदाज कर दिए जाते हैं।

परीक्षण केस सूचना फ़ंक्शन का एक उदाहरण इस प्रकार है:

reboot_node() ->
    [
     {timetrap,{seconds,60}},
     {require,interfaces},
     {userdata,
         [{description,"System Upgrade: RpuAddition Normal RebootNode"},
          {fts,"http://someserver.ericsson.se/test_doc4711.pdf"}]}                  
    ].

5.7 टेस्ट सूट सूचना समारोह

फ़ंक्शन suite/0 , उदाहरण के लिए, एक डिफ़ॉल्ट समय- timetrap मान सेट करने के लिए और बाहरी कॉन्फ़िगरेशन डेटा की require लिए परीक्षण सूट मॉड्यूल में उपयोग किया जा सकता है। यदि कोई परीक्षण केस, या समूह सूचना फ़ंक्शन भी किसी भी सूचना टैग को निर्दिष्ट करता है, तो यह suite/0 द्वारा निर्धारित डिफ़ॉल्ट मानों को ओवरराइड करता है। विवरण के लिए, Test Case Information Function और Test Case Groups

निम्नलिखित विकल्पों को भी सूट सूचना सूची के साथ निर्दिष्ट किया जा सकता है:

सुइट सूचना फ़ंक्शन का एक उदाहरण इस प्रकार है:

suite() ->
    [
     {timetrap,{minutes,10}},
     {require,global_names},
     {userdata,[{info,"This suite tests database transactions."}]},
     {silent_connections,[telnet]},
     {stylesheet,"db_testing.css"}
    ].

5.8 टेस्ट केस ग्रुप

एक परीक्षण मामला समूह विन्यास कार्यों और निष्पादन गुणों को साझा करने वाले परीक्षण मामलों का एक समूह है। टेस्ट केस समूहों को फ़ंक्शन सिंटैक्स द्वारा परिभाषित किया जाता है groups/0 निम्नलिखित सिंटैक्स के अनुसार:

groups() -> GroupDefs

Types:

GroupDefs = [GroupDef]
GroupDef = {GroupName,Properties,GroupsAndTestCases}
GroupName = atom()
GroupsAndTestCases = [GroupDef | {group,GroupName} | TestCase]
TestCase = atom()

GroupName का नाम है और टेस्ट सूट मॉड्यूल के भीतर अद्वितीय होना चाहिए। समूहों को नेस्ट किया जा सकता है, GroupsAndTestCases की एक समूह समूह के भीतर समूह परिभाषा को शामिल करके। Properties समूह के लिए निष्पादन गुणों की सूची है। संभावित मूल्य इस प्रकार हैं:

Properties = [parallel | sequence | Shuffle | {RepeatType,N}]
Shuffle = shuffle | {shuffle,Seed}
Seed = {integer(),integer(),integer()}
RepeatType = repeat | repeat_until_all_ok | repeat_until_all_fail |
             repeat_until_any_ok | repeat_until_any_fail
N = integer() | forever

स्पष्टीकरण:

parallel

Common Test समूह में सभी परीक्षण मामलों को समानांतर में निष्पादित करता है।

sequence

मामलों को एक अनुक्रम में निष्पादित किया जाता है जैसा कि धारा Sequences इन टेस्ट केसेस और सूट के खंड निर्भरता में वर्णित है।

shuffle

समूह में मामलों को यादृच्छिक क्रम में निष्पादित किया जाता है।

repeat

समूह में मामलों के निष्पादन को दोहराने के लिए Common Test आदेश दिए गए हैं, या किसी भी समय तक, या सभी, मामले विफल या सफल होते हैं।

उदाहरण:

groups() -> [{group1, [parallel], [test1a,test1b]},
             {group2, [shuffle,sequence], [test2a,test2b,test2c]}].

यह निर्दिष्ट करने के लिए कि किस क्रम में समूहों को निष्पादित किया जाना है (उन मामलों के परीक्षण के संबंध में जो किसी समूह का हिस्सा नहीं हैं), all/0 सूची में प्रपत्र {group,GroupName} पर tuples जोड़ें।

उदाहरण:

all() -> [testcase1, {group,group1}, testcase2, {group,group2}].

all/0 में समूह टपल के साथ निष्पादन गुण: {group,GroupName,Properties} को भी निर्दिष्ट किया जा सकता है। ये गुण समूह परिभाषा में निर्दिष्ट उन लोगों को ओवरराइड करते हैं (पहले groups/0 देखें groups/0 )। इस तरह, परीक्षणों का एक ही सेट चलाया जा सकता है, लेकिन अलग-अलग गुणों के साथ, समूह परिभाषा की प्रतियां प्रश्न के बिना बनाने के लिए।

यदि किसी समूह में उपसमूह होते हैं, तो इनके लिए निष्पादन गुण समूह समूह में भी निर्दिष्ट किए जा सकते हैं: {group,GroupName,Properties,SubGroups} कहां, SubGroups tuples की एक सूची है, {GroupName,Properties} या {GroupName,Properties,SubGroups} उपसमूहों का प्रतिनिधित्व करना। किसी समूह के लिए group/0 में परिभाषित कोई उपसमूह, जो SubGroups सूची में निर्दिष्ट नहीं हैं, उनके पूर्वनिर्धारित गुणों के साथ निष्पादित होता है।

उदाहरण:

groups() -> {tests1, [], [{tests2, [], [t2a,t2b]},
                          {tests3, [], [t31,t3b]}]}.

हर बार tests2 लिए विभिन्न गुणों के साथ समूह tests1 को निष्पादित करने के लिए:

all() ->
   [{group, tests1, default, [{tests2, [parallel]}]},
    {group, tests1, default, [{tests2, [shuffle,{repeat,10}]}]}].

यह निम्नलिखित विनिर्देश के बराबर है:

all() ->
   [{group, tests1, default, [{tests2, [parallel]},
                              {tests3, default}]},
    {group, tests1, default, [{tests2, [shuffle,{repeat,10}]},
                              {tests3, default}]}].

मान default बताता है कि पूर्वनिर्धारित गुणों का उपयोग किया जाना है।

निम्न उदाहरण से पता चलता है कि कैसे गहरे नेस्टेड समूहों के साथ गुणों को ओवरराइड करने के लिए:

groups() ->
   [{tests1, [], [{group, tests2}]},
    {tests2, [], [{group, tests3}]},
    {tests3, [{repeat,2}], [t3a,t3b,t3c]}].

all() ->
   [{group, tests1, default, 
     [{tests2, default,
       [{tests3, [parallel,{repeat,100}]}]}]}].

वर्णित वाक्यविन्यास का उपयोग परीक्षण के सूट को संपादित करने के बिना, निष्पादन के समय समूह गुणों को बदलने के लिए परीक्षण विनिर्देशों में भी किया जा सकता है। अधिक जानकारी के लिए, अनुभाग रनिंग टेस्ट और विश्लेषण परिणामों में अनुभाग Test Specifications देखें।

जैसा कि सचित्र है, गुणों को जोड़ा जा सकता है। यदि, उदाहरण के लिए, shuffle , repeat_until_any_fail , और sequence सभी निर्दिष्ट हैं, तो समूह में परीक्षण मामलों को बार-बार निष्पादित किया जाता है, और यादृच्छिक क्रम में, जब तक कि एक परीक्षण मामला विफल नहीं हो जाता। फिर निष्पादन तुरंत रोक दिया जाता है और शेष मामलों को छोड़ दिया जाता है।

किसी समूह का निष्पादन शुरू होने से पहले, कॉन्फ़िगरेशन फ़ंक्शन init_per_group(GroupName, Config) कहा जाता है। इस फ़ंक्शन से लौटी टुपल्स की सूची तर्क Config द्वारा सामान्य तरीके से परीक्षण मामलों को पास की जाती है। init_per_group/2 का उपयोग समूह में परीक्षण मामलों के लिए init_per_group/2 लिए किया जाता है। समूह के निष्पादन के समाप्त होने के बाद, फ़ंक्शन end_per_group(GroupName, Config) कहा जाता है। इस फ़ंक्शन का उपयोग init_per_group/2 बाद सफाई के लिए किया जाना है। यदि init फ़ंक्शन परिभाषित है, तो अंतिम फ़ंक्शन होना चाहिए।

जब भी किसी समूह को निष्पादित किया जाता है, अगर init_per_group और end_per_group सुइट में मौजूद नहीं होते हैं, तो Common Test इसके बजाय डमी फ़ंक्शंस (समान नामों के साथ) को कॉल करता है। हुक कार्यों द्वारा उत्पन्न आउटपुट को इन डमी के लिए लॉग फ़ाइलों में सहेजा जाता है। अधिक जानकारी के लिए, अनुभाग कॉमन टेस्ट हुक में सेक्शन Manipulating Tests देखें।

ध्यान दें

init_per_testcase/2 और end_per_testcase/2 को हमेशा प्रत्येक व्यक्तिगत परीक्षण मामले के लिए बुलाया जाता है, भले ही मामला किसी समूह का हो या न हो।

समूह के लिए गुण हमेशा init_per_group/2 लिए HTML लॉग के शीर्ष में मुद्रित होते हैं। किसी समूह के लिए कुल निष्पादन समय end_per_group/2 लिए लॉग के निचले भाग में शामिल है।

टेस्ट केस समूहों को नेस्ट किया जा सकता है इसलिए समूहों के सेटों को समान init_per_group/2 और end_per_group/2 फ़ंक्शन के साथ कॉन्फ़िगर किया जा सकता है। नेस्टेड ग्रुप्स को ग्रुप डेफिनेशन या ग्रुप ग्रुप रेफरेंस को दूसरे ग्रुप के टेस्ट केस लिस्ट में शामिल करके परिभाषित किया जा सकता है।

उदाहरण:

groups() -> [{group1, [shuffle], [test1a,
                                  {group2, [], [test2a,test2b]},
                                  test1b]},
             {group3, [], [{group,group4},
                           {group,group5}]},
             {group4, [parallel], [test4a,test4b]},
             {group5, [sequence], [test5a,test5b,test5c]}].

पिछले उदाहरण में, यदि all/0 समूह के नाम का संदर्भ क्रम में देता है [{group,group1},{group,group3}] , कॉन्फ़िगरेशन फ़ंक्शंस और परीक्षण मामलों का क्रम निम्न हो जाता है (सूचना है कि init_per_testcase/2 और end_per_testcase/2: हमेशा कहा जाता है, लेकिन सरलीकरण के लिए इस उदाहरण में शामिल नहीं):

init_per_group(group1, Config) -> Config1  (*)
     test1a(Config1)
     init_per_group(group2, Config1) -> Config2
          test2a(Config2), test2b(Config2)
     end_per_group(group2, Config2)
     test1b(Config1)
end_per_group(group1, Config1) 
init_per_group(group3, Config) -> Config3
     init_per_group(group4, Config3) -> Config4
          test4a(Config4), test4b(Config4)  (**)
     end_per_group(group4, Config4)
     init_per_group(group5, Config3) -> Config5
          test5a(Config5), test5b(Config5), test5c(Config5)
     end_per_group(group5, Config5)
end_per_group(group3, Config3)

(*) टेस्ट केस टेस्ट 1 test1a , test1b group1 test1b , और group2 का group2 अपरिभाषित है, क्योंकि group2 group1 में एक फेरबदल संपत्ति है।

(**) इन मामलों को आदेश में निष्पादित नहीं किया जाता है, लेकिन समानांतर में।

गुणों को शीर्ष-स्तरीय समूहों से नेस्टेड उपसमूहों से विरासत में नहीं मिला है। उदाहरण के लिए, पिछले उदाहरण में, समूह 2 में परीक्षण के मामलों को यादृच्छिक क्रम में निष्पादित नहीं किया जाता है (जो group1 की संपत्ति है)।

5.9 समानांतर संपत्ति और नेस्टेड समूह

यदि किसी समूह के पास समानांतर संपत्ति है, तो उसके परीक्षण मामलों को एक साथ चलाया जाता है और समानांतर में निष्पादित किया जाता है। हालांकि, एक परीक्षण मामले को end_per_group/2 साथ समानांतर में निष्पादित करने की अनुमति नहीं है, जिसका अर्थ है कि समानांतर समूह को निष्पादित करने का समय समूह में सबसे धीमे परीक्षण मामले के निष्पादन समय के बराबर है। समानांतर में परीक्षण मामलों को चलाने का एक नकारात्मक पक्ष प्रभाव यह है कि HTML सारांश पृष्ठ समूह के समाप्त होने तक फ़ंक्शन end_per_group/2 तक व्यक्तिगत परीक्षण केस लॉग के लिंक के साथ अपडेट नहीं किए जाते हैं।

एक समानांतर समूह के तहत नेस्टेड समूह पिछले (समानांतर) परीक्षण मामलों के साथ समानांतर में निष्पादित करना शुरू कर देता है (कोई फर्क नहीं पड़ता कि क्या नेस्टेड समूह के गुण हैं)। हालाँकि, परीक्षण मामलों को समान समूह के init_per_group/2 या end_per_group/2 के साथ कभी भी निष्पादित नहीं किया जाता है, यह केवल एक नेस्टेड समूह के समाप्त होने के बाद ही होता है कि पिछले समूह में शेष समानांतर मामले end_per_group/2 बन जाते हैं।

5.10 समानांतर टेस्ट मामले और I / O

एक समानांतर परीक्षण के मामले में एक निजी I / O सर्वर है जो इसके समूह का नेता है। (समूह नेता अवधारणा के विवरण के लिए, ERTS देखें)। केंद्रीय I / O सर्वर प्रक्रिया, जो नियमित परीक्षण मामलों और कॉन्फ़िगरेशन फ़ंक्शन से आउटपुट को संभालती है, समानांतर समूहों के निष्पादन के दौरान I / O संदेशों का जवाब नहीं देती है। निम्नलिखित की तरह कुछ जाल से बचने के लिए यह समझना महत्वपूर्ण है:

यदि एक प्रक्रिया, P , के निष्पादन के दौरान पैदा की जाती है, उदाहरण के लिए, init_per_suite/1 , तो यह init_per_suite प्रक्रिया के समूह के नेता को विरासत में init_per_suite है। यह समूह नेता पूर्व में उल्लिखित केंद्रीय I / O सर्वर प्रक्रिया है। यदि बाद के समय में, समानांतर परीक्षण मामले के निष्पादन के दौरान , कुछ ईवेंट io:format/1/2 को कॉल करने के लिए P को ट्रिगर करता है io:format/1/2 , वह कॉल कभी वापस नहीं आती (जैसा कि समूह नेता एक गैर-उत्तरदायी स्थिति में है) और P को लटका देने का कारण बनता है। ।

5.11 दोहराया गया समूह

एक परीक्षण केस समूह को एक निश्चित संख्या में (पूर्णांक द्वारा निर्दिष्ट) या अनिश्चित काल तक ( forever निर्दिष्ट) दोहराया जा सकता है। किसी भी या सभी मामलों के विफल होने या सफल होने पर पुनरावृत्ति को बहुत जल्दी रोका जा सकता है, अर्थात, यदि कोई भी गुण repeat_until_any_fail , repeat_until_any_ok , repeat_until_all_fail , या repeat_until_all_ok का उपयोग किया जाता है। यदि मूल repeat संपत्ति का उपयोग किया जाता है, तो परीक्षण मामलों की स्थिति दोहराने के संचालन के लिए अप्रासंगिक है।

उपसमूह की स्थिति को ऊपर के स्तर पर समूह के निष्पादन को प्रभावित करने के लिए ( ok या failed ) लौटाया जा सकता है। इसके द्वारा पूरा किया जाता है, end_per_group/2 में, Config सूची में tc_group_properties के मूल्य को tc_group_properties हुए और समूह में परीक्षण मामलों के परिणाम की जांच करते हैं। यदि स्थिति के परिणामस्वरूप स्थिति को समूह से वापस किया जाना है, तो end_per_group/2 मान {return_group_result,failed} । किसी समूह के निष्पादन को दोहराया जाना है या नहीं (जब तक कि मूल repeat संपत्ति का उपयोग नहीं किया जाता है) का मूल्यांकन करते समय उपसमूह की स्थिति को Common Test द्वारा ध्यान में रखा जाता है।

tc_group_properties का मान स्टेटस ट्यूपल्स की एक सूची है, प्रत्येक कुंजी के साथ ok , skipped और failed । स्टेटस टपल का मूल्य एक सूची है जिसमें परीक्षण मामलों के नाम हैं जिन्हें परिणाम के रूप में संबंधित स्थिति के साथ निष्पादित किया गया है।

समूह से स्थिति वापस करने का एक उदाहरण निम्नलिखित है:

end_per_group(_Group, Config) ->
    Status = ?config(tc_group_result, Config),
    case proplists:get_value(failed, Status) of
        [] ->                                   % no failed cases 
            {return_group_result,ok};
        _Failed ->                              % one or more failed
            {return_group_result,failed}
    end.

यह संभव भी है, end_per_group/2 , उपसमूह की स्थिति की जांच करने के लिए (शायद यह निर्धारित करने के लिए कि वर्तमान समूह को किस स्थिति में वापस लौटना है)। यह पिछले उदाहरण में सचित्र है, केवल समूह का नाम टपल {group_result,GroupName} में संग्रहीत है, जिसे स्थिति सूचियों में खोजा जा सकता है।

उदाहरण:

end_per_group(group1, Config) ->
    Status = ?config(tc_group_result, Config),
    Failed = proplists:get_value(failed, Status),
    case lists:member({group_result,group2}, Failed) of
          true ->
              {return_group_result,failed};
          false ->                                                    
              {return_group_result,ok}
    end; 
...
ध्यान दें

जब एक परीक्षण केस समूह दोहराया जाता है, तो कॉन्फ़िगरेशन फ़ंक्शन init_per_group/2 और end_per_group/2 भी हमेशा प्रत्येक पुनरावृत्ति के साथ कहा जाता है।

5.12 शफल्ड टेस्ट केस ऑर्डर

जिस क्रम में किसी समूह में परीक्षण मामलों को निष्पादित किया जाता है वह सामान्य परिस्थितियों में होता है, जैसा कि समूह परिभाषा में परीक्षण मामले की सूची में निर्दिष्ट आदेश है। संपत्ति में shuffle सेट के साथ, हालांकि, Common Test इसके बजाय यादृच्छिक क्रम में परीक्षण मामलों को निष्पादित करता है।

आप फेरबदल संपत्ति {shuffle,Seed} साथ एक बीज मूल्य (तीन पूर्णांक का एक टपल) प्रदान कर सकते हैं। इस तरह, एक ही फेरबदल आदेश हर बार समूह निष्पादित होने पर बनाया जा सकता है। यदि कोई बीज मान निर्दिष्ट नहीं किया जाता है, तो Common Test फेरबदल ऑपरेशन के लिए "यादृच्छिक" बीज बनाता है ( erlang:timestamp/0 के वापसी मूल्य का उपयोग करके erlang:timestamp/0 )। बीज मान हमेशा init_per_group/2 लॉग फ़ाइल में मुद्रित किया जाता है ताकि इसे बाद के टेस्ट रन में उसी निष्पादन आदेश को फिर से बनाने के लिए उपयोग किया जा सके।

ध्यान दें

यदि एक फेरबदल परीक्षण केस समूह दोहराया जाता है, तो बीज मुड़ने के बीच रीसेट नहीं होता है।

यदि किसी उपसमूह को shuffle संपत्ति वाले समूह में निर्दिष्ट किया जाता है, तो समूह में परीक्षण मामलों (और अन्य उपसमूह) के संबंध में इस उपसमूह का निष्पादन क्रम यादृच्छिक होता है। उपसमूह में परीक्षण के मामलों का क्रम हालांकि यादृच्छिक नहीं है (जब तक कि उपसमूह में shuffle संपत्ति न हो)।

5.13 समूह सूचना समारोह

टेस्ट केस ग्रुप group(GroupName) फंक्शन, group(GroupName) , सूट के रूप में एक ही उद्देश्य और टेस्ट केस इंफॉर्मेशन फ़ंक्शन को पहले से वर्णित करता है। हालाँकि, समूह सूचना फ़ंक्शन की गुंजाइश, समूह में सभी परीक्षण मामलों और उपसमूहों ( GroupName ) में है।

उदाहरण:

group(connection_tests) ->
   [{require,login_data},
    {timetrap,1000}].

समूह सूचना गुण सुइट सूचना फ़ंक्शन के साथ सेट किए गए लोगों को ओवरराइड करते हैं, और बदले में परीक्षण मामले की जानकारी गुणों द्वारा ओवरराइड किया जा सकता है। मान्य सूचना गुणों और अधिक सामान्य जानकारी की सूची के लिए, Test Case Information Function

5.14 Init- और एंड-कॉन्फ़िगरेशन के लिए सूचना कार्य

सूचना फ़ंक्शंस का उपयोग फ़ंक्शंस init_per_suite , end_per_suite , init_per_group और end_per_group लिए भी किया जा सकता है, और वे उसी तरह काम करते हैं जैसे Test Case Information Function । यह उपयोगी है, उदाहरण के लिए, समय-सारिणी सेट करने के लिए और केवल कॉन्फ़िगरेशन फ़ंक्शन के लिए प्रासंगिक बाहरी कॉन्फ़िगरेशन डेटा की आवश्यकता होती है (सूट में समूहों और परीक्षण मामलों के लिए सेट गुणों को प्रभावित किए बिना)।

सूचना फ़ंक्शन init/end_per_suite() को init/end_per_suite(Config) , और सूचना फ़ंक्शन init/end_per_group(GroupName) को init/end_per_group(GroupName,Config) लिए बुलाया जाता है। हालाँकि, init/end_per_testcase(TestCase, Config) फ़ंक्शन का उपयोग init/end_per_testcase(TestCase, Config) साथ नहीं किया जा सकता है, क्योंकि ये कॉन्फ़िगरेशन फ़ंक्शन टेस्ट केस प्रोसेस पर निष्पादित होते हैं और टेस्ट केस के समान गुणों का उपयोग करते हैं (अर्थात, परीक्षण सूचना सूचना फ़ंक्शन द्वारा सेट किए गए गुण, TestCase() )। मान्य सूचना गुणों और अधिक सामान्य जानकारी की सूची के लिए, Test Case Information Function

5.15 डेटा और निजी निर्देशिकाएँ

डेटा निर्देशिका में data_dir , परीक्षण मॉड्यूल में परीक्षण के लिए आवश्यक अपनी फ़ाइलें हैं। data_dir का नाम टेस्ट सूट का नाम है, जिसके बाद "_data" । उदाहरण के लिए, "some_path/foo_SUITE.beam" में डेटा निर्देशिका "some_path/foo_SUITE_data/" । पोर्टेबिलिटी के लिए इस निर्देशिका का उपयोग करें, अर्थात, अपने सुइट में हार्डकॉइड निर्देशिका नामों से बचने के लिए। चूंकि डेटा निर्देशिका आपके परीक्षण सूट के समान निर्देशिका में संग्रहीत की जाती है, आप रनटाइम पर इसके अस्तित्व पर भरोसा कर सकते हैं, भले ही टेस्ट सूट कार्यान्वयन और निष्पादन के बीच आपके टेस्ट सूट निर्देशिका का मार्ग बदल गया हो।

priv_dir परीक्षण मामलों के लिए निजी निर्देशिका है। जब भी एक परीक्षण मामले (या कॉन्फ़िगरेशन फ़ंक्शन) को फ़ाइल में कुछ लिखने के लिए इस निर्देशिका का उपयोग किया जा सकता है। निजी निर्देशिका का नाम Common Test द्वारा उत्पन्न होता है, जो निर्देशिका भी बनाता है।

डिफ़ॉल्ट रूप से, Common Test प्रत्येक परीक्षण मामलों द्वारा साझा किए गए प्रति टेस्ट रन के लिए एक केंद्रीय निजी निर्देशिका बनाता है। यह हमेशा उपयुक्त नहीं है। विशेष रूप से यदि एक ही परीक्षण के मामलों को एक टेस्ट रन के दौरान कई बार निष्पादित किया जाता है (अर्थात, यदि वे संपत्ति repeat साथ एक परीक्षण केस समूह से संबंधित हैं) और एक जोखिम है कि निजी निर्देशिका में फाइलें अधिलेखित हो जाती हैं। इन परिस्थितियों में, प्रति परीक्षण मामले और निष्पादन के बजाय एक समर्पित निजी निर्देशिका बनाने के लिए Common Test को कॉन्फ़िगर किया जा सकता है। यह ध्वज / विकल्प create_priv_dir ( ct_run प्रोग्राम, ct:run_test/1 फ़ंक्शन के साथ या परीक्षण विनिर्देश अवधि के रूप में उपयोग किया जा सकता है) के साथ पूरा किया गया है। इस विकल्प के लिए तीन संभावित मान निम्न हैं:

  • auto_per_run
  • auto_per_tc
  • manual_per_tc

पहला मान डिफ़ॉल्ट priv_dir व्यवहार को इंगित करता है, priv_dir , एक निजी निर्देशिका प्रति परीक्षण रन बनाई गई है। बाद के दो मूल्य Common Test को प्रति परीक्षण मामले और निष्पादन के लिए एक अद्वितीय परीक्षण निर्देशिका नाम उत्पन्न करने के लिए बताते हैं। यदि ऑटो संस्करण का उपयोग किया जाता है, तो सभी निजी निर्देशिकाएं स्वचालित रूप से बनाई जाती हैं। यह कई परीक्षण मामलों या दोहराव, या दोनों के साथ परीक्षण रन के लिए बहुत अक्षम हो सकता है। इसलिए, यदि इसके बजाय मैनुअल संस्करण का उपयोग किया जाता है, तो टेस्ट केस को priv_dir बनाने के लिए Common Test को बताना चाहिए, जब उसे इसकी आवश्यकता हो। यह फ़ंक्शन ct:make_priv_dir/0 को कॉल करके ऐसा करता है।

ध्यान दें

डेटा फ़ाइलों को पढ़ने और लिखने के लिए वर्तमान कार्य निर्देशिका पर निर्भर न करें, क्योंकि यह पोर्टेबल नहीं है। सभी स्क्रैच फाइल्स को priv_dir में लिखा जाना है और सभी डेटा फाइल्स data_dir में स्थित data_dir । साथ ही, Common Test सर्वर वर्तमान केस निर्देशिका को हर मामले की शुरुआत में टेस्ट केस लॉग डायरेक्टरी में सेट करता है।

5.16 निष्पादन पर्यावरण

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

विन्यास कार्य init_per_suite और end_per_suite निष्पादित होते हैं, परीक्षण मामलों की तरह, समर्पित Erlang प्रक्रियाओं पर।

5.17 टाइमटेप टाइम-आउट

एक परीक्षण के मामले के लिए डिफ़ॉल्ट समय सीमा 30 मिनट है, जब तक कि एक समय-सीमा भी timetrap द्वारा निर्दिष्ट नहीं की जाती timetrap , समूह- या परीक्षण मामले की जानकारी फ़ंक्शन। suite/0 द्वारा परिभाषित टाइम-टाइम टाइम-आउट मान वह मूल्य होता है जो सूट में प्रत्येक परीक्षण मामले के लिए उपयोग किया जाता है (और कॉन्फ़िगरेशन कार्यों के लिए init_per_suite/1 , end_per_suite/1 , init_per_group/2 , और end_per_group/2 )। group(GroupName) द्वारा परिभाषित समय-सीमा मान suite() द्वारा परिभाषित एक को ओवरराइड करता है और समूह GroupName , और उसके किसी भी उपसमूह में प्रत्येक परीक्षण मामले के लिए उपयोग किया जाता है। यदि किसी उपसमूह के लिए group/1 द्वारा समय-सीमा मान को परिभाषित किया जाता है, तो वह अपने उच्च स्तर के समूहों से आगे निकल जाता है। अलग-अलग परीक्षण मामलों (परीक्षण मामले की जानकारी समारोह द्वारा) द्वारा निर्धारित समय-मान दोनों समूह- और सूट-स्तर के समयावधि को ओवरराइड करता है।

एक परीक्षण मामले के निष्पादन या कॉन्फ़िगरेशन फ़ंक्शन के दौरान एक समय-सीमा भी गतिशील रूप से सेट या रीसेट की जा सकती है। यह ct:timetrap/1 को कॉल करके किया जाता है। यह फ़ंक्शन वर्तमान समय-सारणी को रद्द कर देता है और एक नया शुरू करता है (जो कि टाइम-आउट या वर्तमान फ़ंक्शन के अंत तक सक्रिय रहता है)।

टाइमपेट्रैप मानों को मल्टीप्लायर मूल्य के साथ स्टार्टअप पर निर्दिष्ट किया जा सकता है जिसमें विकल्प के साथ multiply_timetraps । यह भी संभव है कि टेस्ट सर्वर को समय-सीमा के टाइम-आउट मानों को स्वचालित रूप से तय करने दें। यही है, अगर परीक्षण के दौरान cover या trace जैसे उपकरण चल रहे हैं। यह सुविधा डिफ़ॉल्ट रूप से अक्षम है और स्टार्ट ऑप्शन scale_timetraps साथ सक्षम की जा सकती है।

यदि एक परीक्षण के मामले में खुद को उस समय के लिए निलंबित करने की आवश्यकता होती है जो multiply_timetraps भी हो जाता scale_timetraps (और संभवतः स्केल स्केल किया जाता है तो scale_timetraps सक्षम होता है), फ़ंक्शन ct:sleep/1 का उपयोग किया जा सकता है (इसके बजाय, उदाहरण के लिए, timer:sleep/1 )।

एक फंक्शन ( fun/0 या {Mod,Func,Args} (एमएफए) {Mod,Func,Args} और टेस्ट केस इंफॉर्मेशन फंक्शन में टाइमट्रैप वैल्यू के रूप में निर्दिष्ट किया जा सकता है, और फ़ंक्शन के लिए तर्क के रूप में ct:timetrap/1

उदाहरण:

{timetrap,{my_test_utils,timetrap,[?MODULE,system_start]}}

ct:timetrap(fun() -> my_timetrap(TestCaseName, Config) end)

उपयोगकर्ता समय-सीमा फ़ंक्शन का उपयोग दो चीजों के लिए किया जा सकता है:

  • समय-सीमा के रूप में कार्य करने के लिए। फ़ंक्शन वापस आने पर टाइम-आउट चालू हो जाता है।
  • समय-सीमा समय मान (किसी फ़ंक्शन के अलावा) वापस करने के लिए।

टाइमट्रैप फ़ंक्शन (जो एक समानांतर, समर्पित टाइमट्रैप प्रक्रिया पर किया जाता है) के निष्पादन से पहले, Common Test टेस्ट केस या कॉन्फ़िगरेशन फ़ंक्शन के लिए किसी भी पहले से निर्धारित टाइमर को रद्द कर देता है। जब समय-सीमा फ़ंक्शन लौटता है, तो टाइम-आउट चालू हो जाता है, जब तक कि रिटर्न वैल्यू एक वैध समय-सीमा समय नहीं होती है, जैसे कि पूर्णांक, या {SecMinOrHourTag,Time} tuple (विवरण के लिए {SecMinOrHourTag,Time} देखें)। यदि समय मान लौटाया जाता है, तो निर्दिष्ट समय के बाद टाइम-आउट जनरेट करने के लिए एक नई समय-सीमा शुरू की जाती है।

उपयोगकर्ता समय-सीमा फ़ंक्शन देरी के बाद समय मान लौटा सकता है। प्रभावी समय-सीमा समय तब विलंब समय और लौटा समय है।

5.18 लॉगिंग - श्रेणियाँ और शब्दशः स्तर

Common Test मुद्रण स्ट्रिंग्स के लिए निम्नलिखित तीन मुख्य कार्य प्रदान करता है:

  • ct:log(Category, Importance, Format, FormatArgs, Opts)
  • ct:print(Category, Importance, Format, FormatArgs)
  • ct:pal(Category, Importance, Format, FormatArgs)

log/1,2,3,4,5 समारोह परीक्षण का मामला लॉग फ़ाइल के लिए एक स्ट्रिंग प्रिंट करता है। print/1,2,3,4 समारोह स्ट्रिंग स्क्रीन करने के लिए प्रिंट करता है। pal/1,2,3,4 समारोह में एक ही स्ट्रिंग दोनों फ़ाइल और स्क्रीन को प्रिंट करता है। मॉड्यूल में कार्यों का वर्णन किया गया है ct

वैकल्पिक Category तर्क का उपयोग लॉग प्रिंटआउट को वर्गीकृत करने के लिए किया जा सकता है। श्रेणियों का उपयोग दो चीजों के लिए किया जा सकता है:

  • प्रिंटआउट के महत्व की तुलना एक विशिष्ट वर्बोसिटी स्तर तक करने के लिए।
  • उपयोगकर्ता-विशिष्ट HTML स्टाइल शीट (CSS) के अनुसार प्रिंटआउट को प्रारूपित करने के लिए।

तर्क Importance एक महत्व के स्तर को निर्दिष्ट करता है, जो एक वर्बोसिटी स्तर (सामान्य और / या प्रति श्रेणी निर्धारित) की तुलना में, निर्धारित करता है कि क्या प्रिंटआउट दिखाई देना है। Importance 0..99 की सीमा में कोई पूर्णांक है। ct.hrl शीर्ष लेख फ़ाइल में पूर्वनिर्धारित स्थिरांक मौजूद होते हैं । डिफ़ॉल्ट महत्व स्तर, ?STD_IMPORTANCE (इस्तेमाल किया है, तो तर्क Importance प्रदान नहीं की है), 50. है यह भी मानक मैं के लिए इस्तेमाल किया महत्व है / हे, उदाहरण के लिए, के साथ बनाया प्रिंटआउट से io:format/2 , io:put_chars/1 , और इतने पर।

Importance verbosity शुरुआत ध्वज / विकल्प द्वारा निर्धारित एक वर्बोसिटी स्तर की तुलना में है । स्तर प्रति श्रेणी या आम तौर पर, या दोनों में सेट किया जा सकता है। यदि verbosity उपयोगकर्ता द्वारा सेट नहीं किया गया है, तो 100 ( ?MAX_VERBOSITY = सभी प्रिंटआउट दिखाई देने वाले) का स्तर डिफ़ॉल्ट मान के रूप में उपयोग किया जाता है। Common Test निम्नलिखित परीक्षण करता है:

Importance >= (100-VerbosityLevel)

स्थिरांक ?STD_VERBOSITY का मान 50 (देखें ct.hrl ) है। इस स्तर पर, सभी मानक I / O मुद्रित हो जाते हैं। यदि कम वर्बोसिटी स्तर सेट किया गया है, तो मानक I / O प्रिंटआउट को अनदेखा किया जाता है। वर्बोसिटी लेवल 0 प्रभावी रूप से सभी लॉगिंग को बंद कर देता है (केवल Common Test अपने द्वारा बनाए गए प्रिंटआउट को छोड़कर )।

सामान्य वर्बोसिटी स्तर किसी विशेष श्रेणी से जुड़ा नहीं है। यह स्तर मानक I / O प्रिंटआउट, अनियंत्रित ct:log/print/pal प्रिंटआउट, और अपरिभाषित वर्बोसिटी स्तर वाली श्रेणियों के लिए प्रिंटआउट के लिए सीमा निर्धारित करता है।

उदाहरण:

परीक्षण मामले के निष्पादन के दौरान कुछ प्रिंटआउट:

io:format("1. Standard IO, importance = ~w~n", [?STD_IMPORTANCE]),
ct:log("2. Uncategorized, importance = ~w", [?STD_IMPORTANCE]),
ct:log(info, "3. Categorized info, importance = ~w", [?STD_IMPORTANCE]),
ct:log(info, ?LOW_IMPORTANCE, "4. Categorized info, importance = ~w", [?LOW_IMPORTANCE]),
ct:log(error, ?HI_IMPORTANCE, "5. Categorized error, importance = ~w", [?HI_IMPORTANCE]),
ct:log(error, ?MAX_IMPORTANCE, "6. Categorized error, importance = ~w", [?MAX_IMPORTANCE]),

यदि 50 के सामान्य वर्बोसिटी स्तर के साथ परीक्षण शुरू करना ( ?STD_VERBOSITY ):

$ ct_run -verbosity 50

निम्नलिखित मुद्रित है:

1. Standard IO, importance = 50
2. Uncategorized, importance = 50
3. Categorized info, importance = 50
5. Categorized error, importance = 75
6. Categorized error, importance = 99

यदि परीक्षण की शुरुआत:

$ ct_run -verbosity 1 and info 75

निम्नलिखित मुद्रित है:

3. Categorized info, importance = 50
4. Categorized info, importance = 25
6. Categorized error, importance = 99

ध्यान दें कि केवल एक प्रिंटआउट के महत्व को निर्दिष्ट करने के लिए श्रेणी तर्क की आवश्यकता नहीं है। उदाहरण:

ct:pal(?LOW_IMPORTANCE, "Info report: ~p", [Info])

या शायद स्थिरांक के साथ संयोजन में:

-define(INFO, ?LOW_IMPORTANCE).
-define(ERROR, ?HI_IMPORTANCE).

ct:log(?INFO, "Info report: ~p", [Info])
ct:pal(?ERROR, "Error report: ~p", [Error])

कार्यों ct:set_verbosity/2 और ct:get_verbosity/1 परीक्षण निष्पादन के दौरान वर्बोसिटी स्तरों को संशोधित करने और पढ़ने के लिए उपयोग किया जा सकता है।

तर्क Format और FormatArgs में ct:log/print/pal हमेशा STDLIB समारोह को भेजी जाती हैं io:format/3 (विवरण के लिए, io मैन्युअल पृष्ठ)।

ct:pal/4 और ct:log/5 लॉग फ़ाइल में मुद्रित होने वाले स्ट्रिंग्स में हेडर जोड़ें। तार को सीएसएस वर्ग विशेषता के साथ div टैग में भी लपेटा जाता है, ताकि स्टाइलशीट फॉर्मेटिंग को लागू किया जा सके। प्रिंटआउट के लिए इस सुविधा को अक्षम करने के लिए (अर्थात उपयोग करने के समान परिणाम प्राप्त करने के लिए io:format/2 ), विकल्प के ct:log/5 साथ कॉल करें no_css

सीएसएस को टैग कैसे श्रेणियों में मैप किया जा सकता है यह अनुभाग HTML Style Sheets में चल रहे टेस्ट और विश्लेषण परिणामों में अनुभाग में दर्ज़ किया गया है।

कॉमन टेस्ट विशेष HTML वर्णों (<,> और &) से प्रिंटआउट में लॉग फ़ाइल के साथ बनाया जाएगा ct:pal/4 और io:format/2 । लॉग में HTML टैग के साथ स्ट्रिंग्स प्रिंट करने के लिए, ct:log/3,4,5 फ़ंक्शन का उपयोग करें । चरित्र से बचने की सुविधा डिफ़ॉल्ट रूप से अक्षम है, ct:log/3,4,5 लेकिन सूची esc_chars में विकल्प के साथ सक्षम किया जा सकता है Opts , देखें ct:log/3,4,5

यदि चरित्र से बचने की सुविधा को अक्षम करने की आवश्यकता है (आमतौर पर पश्चगामी संगतता कारणों से), ct_run प्रारंभ ध्वज का उपयोग करें -no_esc_chars , या ct:run_test/1 प्रारंभ विकल्प {esc_chars,Bool} (यह प्रारंभ विकल्प भी परीक्षण विनिर्देशों में समर्थित है)।

लॉग फ़ाइलों के बारे में अधिक जानकारी के लिए, Log Files अनुभाग रनिंग टेस्ट और विश्लेषण परिणामों में अनुभाग देखें ।

५.१ ९ अवैध निर्भरताएँ

भले ही यह Common Test फ्रेम के साथ टेस्ट सूट लिखने के लिए अत्यधिक कुशल है , लेकिन गलतियों को मुख्य रूप से अवैध निर्भरता के कारण किया जा सकता है। Erlang / OTP परीक्षण सूट चलाने के साथ अपने स्वयं के अनुभव से कुछ अधिक लगातार गलतियाँ:

  • वर्तमान निर्देशिका और वहां लेखन पर निर्भर करता है:

    परीक्षण सूट में यह एक सामान्य त्रुटि है। यह माना जाता है कि वर्तमान निर्देशिका वैसी ही है जैसा कि लेखक को वर्तमान निर्देशिका के रूप में प्रयोग किया जाता है जब परीक्षण मामले का विकास हुआ था। कई परीक्षण मामले भी इस निर्देशिका के लिए खरोंच फ़ाइलों को लिखने की कोशिश करते हैं। इसके बजाय data_dir और priv_dir डेटा का पता लगाने और स्क्रैच फ़ाइलों को लिखने के लिए उपयोग किया जाना है।

  • निष्पादन आदेश के आधार पर:

    परीक्षण सूट के विकास के दौरान, परीक्षण के मामलों या मुकदमा के निष्पादन आदेश पर कोई धारणा न बनाएं। उदाहरण के लिए, एक परीक्षण मामले को यह नहीं मानना ​​चाहिए कि यह जिस सर्वर पर निर्भर करता है वह पहले से ही पिछले परीक्षण के मामले से शुरू होता है। इसके कारण निम्न हैं:

    • उपयोगकर्ता / ऑपरेटर इच्छा पर आदेश को निर्दिष्ट कर सकता है, और शायद एक अलग निष्पादन आदेश कभी-कभी अधिक प्रासंगिक या कुशल होता है।
    • यदि उपयोगकर्ता परीक्षण के लिए परीक्षण सूट की पूरी निर्देशिका निर्दिष्ट करता है, तो सुइट्स का निष्पादन क्रम इस बात पर निर्भर करता है कि फाइलें ऑपरेटिंग सिस्टम द्वारा कैसे सूचीबद्ध की जाती हैं, जो सिस्टम के बीच भिन्न होती हैं।
    • यदि कोई उपयोगकर्ता केवल परीक्षण सूट का एक सबसेट चलाना चाहता है, तो कोई तरीका नहीं है कि एक परीक्षण मामला सफलतापूर्वक दूसरे पर निर्भर हो सकता है।
  • यूनिक्स पर निर्भर करता है:

    के माध्यम से यूनिक्स कमांड चलाना os:cmd गैर-यूनिक्स प्लेटफार्मों पर काम नहीं करने की संभावना है।

  • नेस्टेड परीक्षण के मामले:

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

    कई टेस्ट केस फंक्शन्स के लिए फंक्शनलिटी कॉमन हेल्प फंक्शन्स में लागू की जा सकती है। यदि ये कार्य सुइट्स में परीक्षण के मामलों के लिए उपयोगी हैं, तो सहायता कार्यों को सामान्य सहायता मॉड्यूल में डाल दें।

  • क्रैश या बाहर निकलने में विफलता जब चीजें गलत हो जाती हैं:

    बिना जांच किए अनुरोध करना कि रिटर्न वैल्यू इंगित करता है कि सफलता ठीक है यदि परीक्षण का मामला बाद में विफल हो जाता है, लेकिन यह केवल एक त्रुटि संदेश (लॉग फाइल में) प्रिंट करने और सफलतापूर्वक वापस आने के लिए स्वीकार्य नहीं है। इस तरह के परीक्षण मामले नुकसान करते हैं, क्योंकि वे परीक्षा परिणामों का अवलोकन करते समय सुरक्षा की झूठी भावना पैदा करते हैं।

  • बाद के परीक्षण मामलों के लिए मेसिंग:

    परीक्षण मामलों को जितना संभव हो उतना निष्पादन पर्यावरण को पुनर्स्थापित करना है, ताकि बाद के परीक्षण के मामले उनके निष्पादन आदेश के कारण दुर्घटनाग्रस्त न हों। इसके लिए समारोह end_per_testcase/2 उपयुक्त है।

Original text