Erlang 21 - 3. Getting Started

3 शुरू हो रहा है




erlang

3 शुरू हो रहा है

3.1 नवागंतुकों के लिए परिचय

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

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

ध्यान दें

यह समझने के लिए कि यहाँ क्या चर्चा और जाँच की गई है, हमने आपको पहले Common Test Basics पढ़ने की सिफारिश की है।

3.2 टेस्ट केस निष्पादन

परीक्षण मामलों के निष्पादन निम्नानुसार हैं:

चित्र 3.1: सफल और असफल टेस्ट केस निष्पादन

प्रत्येक परीक्षण मामले के लिए जिसे Common Test निष्पादित करने का आदेश दिया जाता है, यह एक समर्पित प्रक्रिया को जन्म देता है, जिस पर टेस्ट केस फ़ंक्शन चलना शुरू होता है। (परीक्षण केस प्रक्रिया के समानांतर, एक निष्क्रिय प्रतीक्षा टाइमर प्रक्रिया शुरू की जाती है, जो परीक्षण केस प्रक्रिया से जुड़ी होती है। यदि टाइमर प्रक्रिया प्रतीक्षा समय से बाहर हो जाती है, तो यह परीक्षण मामले की प्रक्रिया को समाप्त करने के लिए एक निकास संकेत भेजती है। यह जिसे समय- सीमा कहा जाता है)।

परिदृश्य 1 में, परीक्षण केस प्रक्रिया सामान्य रूप से समाप्त हो जाती है जब case A ने किसी भी त्रुटि का पता लगाए बिना अपने परीक्षण कोड को निष्पादित करना समाप्त कर दिया है। परीक्षण केस फ़ंक्शन एक मान लौटाता है और Common Test केस को सफल बनाता है।

परिदृश्य 2 में, परीक्षण case B निष्पादन के दौरान एक त्रुटि पाई गई है। यह एक अपवाद उत्पन्न करने के लिए परीक्षण case B फ़ंक्शन का कारण बनता है और, परिणामस्वरूप, परीक्षण मामले की प्रक्रिया सामान्य के अलावा अन्य कारण से बाहर निकलती है। Common Test इसे असफल (विफल) परीक्षण मामले के रूप में लॉग करता है।

जैसा कि आप चित्रण से समझ सकते हैं, असफलता को इंगित करने के लिए एक रनटाइम त्रुटि उत्पन्न करने के लिए Common Test को टेस्ट केस की आवश्यकता होती है (उदाहरण के लिए, खराब मिलान त्रुटि के कारण या exit/1 कॉल करके, अधिमानतः मदद फ़ंक्शन ct:fail/1,2 माध्यम से ct:fail/1,2 )। एक सफल निष्पादन परीक्षण केस फ़ंक्शन से एक सामान्य रिटर्न द्वारा इंगित किया जाता है।

3.3 एक साधारण टेस्ट सूट

जैसा कि अनुभाग Common Test Basics में दिखाया गया है, टेस्ट सूट मॉड्यूल विभिन्न उद्देश्यों के लिए callback functions (अनिवार्य या वैकल्पिक) लागू करता है, उदाहरण के लिए:

  • परीक्षण सूट के लिए इनिट / एंड कॉन्फ़िगरेशन फ़ंक्शन
  • परीक्षण मामले के लिए इनिट / एंड कॉन्फ़िगरेशन फ़ंक्शन
  • परीक्षण केस समूह के लिए इनिट / एंड कॉन्फ़िगरेशन फ़ंक्शन
  • परीक्षण के मामलों

कॉन्फ़िगरेशन फ़ंक्शन वैकल्पिक हैं। निम्न उदाहरण विन्यास कार्यों के बिना एक परीक्षण सूट है, जिसमें एक साधारण परीक्षण मामला भी शामिल है, यह जांचने के लिए कि मॉड्यूल mymod मौजूद है (अर्थात, कोड सर्वर द्वारा सफलतापूर्वक लोड किया जा सकता है):

-module(my1st_SUITE).
-compile(export_all).

all() ->
    [mod_exists].

mod_exists(_) ->
    {module,mymod} = code:load_file(mymod).

यदि ऑपरेशन विफल हो जाता है, तो एक खराब मिलान त्रुटि होती है जो परीक्षण मामले को समाप्त कर देती है।

3.4 कॉन्फ़िगरेशन फ़ंक्शंस के साथ एक टेस्ट सूट

यदि आपको अपना परीक्षण चलाने के लिए कॉन्फ़िगरेशन ऑपरेशन करने की आवश्यकता है, तो आप अपने सूट में कॉन्फ़िगरेशन फ़ंक्शन को लागू कर सकते हैं। कॉन्फ़िगरेशन फ़ंक्शन का परिणाम कॉन्फ़िगरेशन डेटा या Config । यह कुंजी-मूल्य टुपल्स की एक सूची है जो कॉन्फ़िगरेशन फ़ंक्शन से परीक्षण मामलों तक पहुंच जाती है (संभवतः "निचले स्तर" पर कॉन्फ़िगरेशन फ़ंक्शन के माध्यम से)। डेटा प्रवाह निम्नानुसार दिखता है:

चित्रा 3.2: एक सूट में विन्यास डेटा प्रवाह

निम्न उदाहरण एक परीक्षण सूट दिखाता है जो परीक्षण मामलों के लिए एक लॉग फ़ाइल को खोलने और बंद करने के लिए कॉन्फ़िगरेशन फ़ंक्शन का उपयोग करता है (एक ऑपरेशन जो प्रत्येक परीक्षण मामले द्वारा प्रदर्शन करने के लिए अनावश्यक और अप्रासंगिक है):

 -module(check_log_SUITE).
 -export([all/0, init_per_suite/1, end_per_suite/1]).
 -export([check_restart_result/1, check_no_errors/1]).

 -define(value(Key,Config), proplists:get_value(Key,Config)).

 all() -> [check_restart_result, check_no_errors].

 init_per_suite(InitConfigData) ->
     [{logref,open_log()} | InitConfigData].

 end_per_suite(ConfigData) ->
     close_log(?value(logref, ConfigData)).

 check_restart_result(ConfigData) ->
     TestData = read_log(restart, ?value(logref, ConfigData)),
     {match,_Line} = search_for("restart successful", TestData).

 check_no_errors(ConfigData) ->
     TestData = read_log(all, ?value(logref, ConfigData)),
     case search_for("error", TestData) of
{match,Line} -> ct:fail({error_found_in_log,Line});
nomatch -> ok
     end.

परीक्षण मामले सत्यापित करते हैं, एक लॉग फ़ाइल पार्स करके, कि हमारे SUT ने एक सफल पुनरारंभ किया है और कोई भी अप्रत्याशित त्रुटि नहीं छपी है।

हाल ही के परीक्षण सूट में परीक्षण के मामलों को निष्पादित करने के लिए, UNIX / Linux कमांड लाइन (वर्तमान काम करने वाले निर्देशिका में सूट मॉड्यूल है यह मानते हुए) पर निम्न टाइप करें:

$ ct_run -dir .

या:

$ ct_run -suite check_log_SUITE

हमारे परीक्षण को चलाने के लिए एरलैंग शेल का उपयोग करने के लिए, आप निम्नलिखित कॉल का मूल्यांकन कर सकते हैं:

1> ct:run_test([{dir, "."}]).

या:

1> ct:run_test([{suite, "check_log_SUITE"}]).

परीक्षण चलाने से परिणाम HTML प्रारूप में लॉग फ़ाइलों में मुद्रित होता है (एक अलग स्तर पर अद्वितीय लॉग निर्देशिकाओं में संग्रहीत)। निम्न चित्रण लॉग फ़ाइल संरचना दिखाता है:

चित्र 3.3: HTML लॉग फ़ाइल संरचना

3.5 प्रश्न और उत्तर

यहां कुछ सवालों के जवाब दिए गए हैं, जो आपके पास इस अनुभाग को पढ़ने के बाद संबंधित सुझावों और उत्तरों के लिंक के साथ हो सकते हैं:

  • प्रश्न: "मैं अपने परीक्षणों के लिए चर डेटा को कैसे और कहां निर्दिष्ट कर सकता हूं जो परीक्षण सूट (जैसे होस्टनाम, पते और उपयोगकर्ता लॉगिन डेटा) में हार्ड-कोडेड नहीं होना चाहिए?"

    उत्तर: खंड External Configuration Data देखें।

  • प्रश्न: "क्या अलग-अलग परीक्षणों की घोषणा करने और उन्हें एक सत्र में चलाने के लिए मेरी स्क्रिप्ट लिखने के बिना एक तरीका है? इसके अलावा, क्या ऐसी घोषणाओं का उपयोग प्रतिगमन परीक्षण के लिए किया जा सकता है?"

    उत्तर: सेक्शन रनिंग टेस्ट और विश्लेषण परिणामों में सेक्शन Test Specifications को देखें।

  • प्रश्न: "क्या मामलों और / या परीक्षणों को स्वचालित रूप से दोहराया जा सकता है?"

    उत्तर: Test Case Groups बारे में अधिक जानें और सेक्शन Running Tests और रेफरेंस मैनुअल में झंडे / विकल्प के बारे में पढ़ें।

  • प्रश्न: "क्या Common Test मेरे परीक्षण मामलों को अनुक्रम में या समानांतर में निष्पादित करता है?"

    उत्तर: Test Case Groups राइटिंग टेस्ट सूट में सेक्शन Test Case Groups देखें।

  • प्रश्न: "समय-सारिणी (पहले उल्लेखित) के लिए वाक्यविन्यास क्या है, और मैं उन्हें कैसे सेट करूँ?"

    उत्तर: यह राइटिंग टेस्ट सूट के सेक्शन के Timetrap Time-Outs भाग में बताया गया है।

  • प्रश्न: "लॉगिंग और प्रिंटिंग के लिए कौन से कार्य उपलब्ध हैं?"

    उत्तर: टेस्ट राइटिंग टेस्ट सेक्शन में Logging देखें।

  • प्रश्न: "मुझे अपने परीक्षणों के लिए डेटा फ़ाइलों की आवश्यकता है। मैं उन्हें अधिमानतः कहां संग्रहीत करूं?"

    उत्तर: Data and Private Directories देखें।

  • प्रश्न: "क्या मैं एक परीक्षण सूट उदाहरण के साथ शुरू कर सकता हूं, कृपया?"

    उत्तर: Welcome!

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