आप एक फ़ंक्शन का परीक्षण कैसे करते हैं जिसका एकमात्र उद्देश्य बाहरी एपीआई को क्वेरी करना है, लेकिन एपीआई एक जटिल क्वेरी सिंटैक्स का उपयोग करता है?


16

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

function retrieve_related_data(id)
{
  query = "[potentially long, syntactically complex query that
            uses param id to get some data]";
  results = api_wrapper.query(query);
  return results;
}

एक बनाया एपीआई के साथ एक और अधिक ठोस उदाहरण:

function retrieveLifeSupportingObjectsWithinRegion(id)
{
  query = "
    within region(" + id + ") as r
    find objects matching hydration>0 and temp_range has 75
    send name, id, relative(position, r)        
  ";
  results = astronomicalObjectApiWrapper.query(query);
  return results;
}

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

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

मैंने जिन विकल्पों पर विचार किया है:

  1. मैं एपि को स्टब कर सकता हूं, लेकिन यह या तो बहुत सरल होगा (जांचें कि idक्वेरी में मौजूद है और फिर डेटा का अपेक्षित सेट लौटाएं यदि यह है या अप्रत्याशित सेट नहीं है तो), बहुत भंगुर (चेक करें कि क्वेरी स्ट्रिंग है) वास्तव में फ़ंक्शन में क्या है), या बहुत जटिल है (जांचें कि उपयोग की जाने वाली क्वेरी वाक्यविन्यास रूप से सही है और परिणामस्वरूप सही डेटा वापस आ जाएगा)।

  2. मैं वास्तविक एपीआई के लिए क्वेरी जमा कर सकता था, लेकिन अपेक्षित परिणाम समय के साथ बदल सकते थे क्योंकि बाहरी प्रणाली में डेटा बदल जाता था, परीक्षण प्रणाली के नियंत्रण के बाहर।

  3. मैं डेटा को नियंत्रित करने के लिए वास्तविक एपीआई की एक परीक्षण स्थापना स्थापित करने के लिए देख सकता हूं, लेकिन यह बहुत प्रयास है।

मैं # 2 की ओर झुक रहा हूं और इसे अधिक एकीकरण परीक्षण बना रहा हूं जो अक्सर नहीं चलता है और यह देखते हुए कि बाहरी सिस्टम के डेटा में कितनी बार परिवर्तन होता है, जिससे परीक्षण टूट जाता है। मुझे लगता है कि यह अब के लिए सबसे सरल होगा, लेकिन मैं सोच रहा हूं कि क्या ऐसे विकल्प हैं जो मैं इस मुद्दे से निपटने के लिए या बेहतर तरीकों के बारे में नहीं सोच रहा हूं। किसी भी सलाह की सराहना की जाएगी।


मैं इसे एक इकाई परीक्षण के रूप में सोच रहा था, लेकिन शायद यह वास्तव में एकीकरण परीक्षण या निम्न-स्तरीय स्वीकृति परीक्षण है?
जोशुआ कोआदी

2
क्या यह केवल पढ़ने के लिए एपीआई है? या, क्या आप उन आंकड़ों को लिखने में सक्षम हैं, जिनके विरुद्ध आप अपने रीड को सत्यापित कर सकते हैं ?
svidgen

क्या यह सवाल "कैसे परीक्षण करने के लिए कि मेरे sql (= जटिल वाक्यविन्यास) correnct डेटा देता है" से अलग है? डेटाबेस के साथ आमतौर पर आपके पास कुछ एकीकरण परीक्षण होते हैं जो व्यवसायिकता को सत्यापित करने के लिए crud-sql-syntax और एक नकली रिपॉजिटरी फैस का परीक्षण करते हैं
k3b

जवाबों:


7

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

हमारे परीक्षणों को हमारे द्वारा लिखे गए कोड के अपेक्षित व्यवहार की गारंटी देने के लिए संबोधित किया जाना चाहिए, न कि 3 पार्टियों द्वारा लिखित।

कुछ हद तक, हमें उन एपीआई और कामों के उचित कार्य पर भरोसा करना होगा जिन पर हम भरोसा करते हैं। उदाहरण के लिए, हम आमतौर पर हमारे द्वारा लागू किए गए फ्रेमवर्क घटकों का परीक्षण नहीं करते हैं।

मेरे द्वारा ऐसा क्यों कहा जाएगा?

मैं जो परीक्षण करना चाहता हूं वह यह है कि किसी दिए गए इनपुट आईडी के लिए डेटा का सही सेट लौटाया जाए

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

एक अलग चिंता अनुबंध को मान्य करना है। मुझे लगता है कि एकीकरण किसी भी रिलीज या तैनाती से पहले यह सुनिश्चित करने के लिए एक अनुबंध परीक्षण 1 के लिए काफी उपयोगी होगा ।

मैं इसका परीक्षण करना चाहता हूं ताकि अगर कोई इस तरह से प्रश्न को गड़बड़ करे तो यह अब आईडी पर आधारित सही डेटा नहीं लौटाएगा जो विफल हो जाएगा

क्या होगा यदि क्वेरी ठीक है, लेकिन एपीआई में बग के कारण डेटा गलत है? इतना ही नहीं डेटा हमारे नियंत्रण से बाहर है। तर्क भी है।

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

लेकिन मैं यह भी चाहता हूं कि लोग परीक्षण को संशोधित करने की आवश्यकता के बिना इसे परिष्कृत करने के लिए क्वेरी को संशोधित करने में सक्षम हों।

मैं इस तरह के उद्देश्य के लिए एक उपकरण को लागू करने का सुझाव देता हूं। यह उतना ही सरल हो सकता है:

  • एक वर्ग जो परीक्षण के रूप में चलता है, लेकिन यह परीक्षण योजना से संबंधित नहीं है
  • एक शेल स्क्रिप्ट + कर्ल

या कुछ और अधिक परिष्कृत। उदाहरण के लिए, एक स्टैंडअलोन क्लाइंट।

किसी भी मामले में, सवाल के तहत कार्य, अच्छी तरह से दो प्रकार के परीक्षण:

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

  • जोड़ने का परीक्षण। जांचें कि कोड न केवल सही अनुरोध भेजता है, बल्कि यह प्रतिक्रिया सामग्री, त्रुटियों, रीडायरेक्ट आदि को ठीक से संभालता है। इन सभी मामलों के लिए परीक्षण करें, लेकिन डेटा का परीक्षण न करें

साइड नोट: आपका प्रश्न किस तरह से है - क्या आप ऐप के एसक्यूएल स्टेटमेंट का परीक्षण करते हैं-?

संबंधित प्रश्न :


1: इस विषय से संबंधित @ DocBrown के उत्तर में आपकी रुचि हो सकती है


"समस्या (IMO) यह है कि आप बाहरी एपीआई के परीक्षण पर बहुत अधिक ध्यान केंद्रित कर रहे हैं।" - मुझे यह संकेत देते हुए कुछ भी नहीं दिख रहा है कि पूछने वाला बाहरी एपीआई का परीक्षण करने में रुचि रखता है। इसके अलावा, आप कहते हैं "बाहरी एपीआई को ठूंठ", लेकिन क्या आपके पास कोई सुझाव है कि क्या पूछने वाले को "बहुत सरल" विकल्प, "बहुत भंगुर" विकल्प, "बहुत जटिल" विकल्प, या कुछ चौथा विकल्प का उपयोग करना चाहिए?
टान्नर स्विट

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

1
मैं क्वेरी को "हमारे द्वारा लिखा गया कोड" मानता हूं। यदि हम अपने कोड में बग की शुरुआत करते हैं, तो हमें सूचित करने के लिए अंतिम-लक्ष्य स्वचालित परीक्षण है। SQL स्टेटमेंट्स के बारे में आपने जो कहा है, उसे ध्यान में रखते हुए, मुझे लगता है कि यह उसी के समान है - मुझे लगता है कि मेरा सवाल यह है कि आप कैसे परीक्षण करते हैं कि आपका कोड एक बाहरी एपीआई को इस तरीके से क्वेरी कर रहा है कि एपीआई प्रतिक्रिया के अनुसार प्रतिक्रिया देगा (मान लेते हुए नाममात्र की प्रतिक्रिया)। मुझे लगता है कि आप जो कह रहे हैं वह यूनिट और एकीकरण परीक्षणों से बाहर जाना है, लेकिन यदि प्रश्न महत्वपूर्ण हैं, तो हम लाइव बाहरी एपीआई का परीक्षण करने के लिए कुछ अन्य स्वचालित परीक्षणों को अलग से सेट कर सकते हैं।
जोशुआ कोअडी

1
आईएमओ, सबसे अच्छा तरीका कार्यात्मक परीक्षण कर रहा है, जहां क्लॉज जो कभी सच नहीं होने वाला है, में परिवर्तन, मेरे कार्यात्मक परीक्षणों में से एक या अधिक में एक अलग व्यवहार का कारण होगा। परीक्षण योजना में यूटी केवल एक छोटा सा टुकड़ा है।
लॉव

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

2

मैंने यूनिट चेक देखे हैं जो जनरेट किए गए क्वेरी स्ट्रिंग को एक अपेक्षित मान से मेल खाते हैं।

तथापि। सीमित उपयोग अगर यह मेरी राय में था। क्वेरी सिंटैक्स जटिल था, संभवतः छोटी गाड़ी, इसलिए A में चेक करने की अनंत संभावनाएं थीं और B तब भी जब स्ट्रिंग 'सही ढंग से' उत्पन्न हुई थी, लाइव वातावरण में अप्रत्याशित परिणाम वापस आ सकते हैं।

मुझे लगता है कि आप अपने विकल्प के लिए जाने के लिए सही हैं। लाइव उदाहरण के खिलाफ एकीकरण परीक्षण चलाएं।

जब तक वे गैर विनाशकारी होते हैं, ये पहले परीक्षण हैं जिन्हें आपको लिखना चाहिए, क्योंकि वे पकड़ लेंगे, हालांकि, किसी भी त्रुटि के कारण की पहचान नहीं करें।

विकल्प 3 के लिए जाना 'डमी डेटा के साथ एक परीक्षण उदाहरण को तैनात करना' बेहतर है। लेकिन आपके परीक्षण लेखन को प्रभावित नहीं करता है, जैसा कि आप परीक्षण सर्वर पर एक ही परीक्षण को इंगित कर सकते हैं यदि यह एक को तैनात करने के लिए समय का एक अच्छा उपयोग हो जाता है।


0

यह एपीआई पर निर्भर करता है, लेकिन यदि संभव हो, तो विकल्प # 3 (निजी परीक्षण उदाहरण) पर जाएं।

एपीआई (विकल्प # 1) को ठोकर देना सबसे खराब विकल्प है, क्योंकि आपने जिन कारणों का उल्लेख किया है, और इस मार्ग पर जाने से शायद अच्छे (बहुत समय बर्बाद होने) की तुलना में अधिक नुकसान होगा।

असली एपीआई (विकल्प # 2) के खिलाफ दौड़ना परीक्षण को परतदार और अविश्वसनीय बनाता है, और कुछ गलत सकारात्मक के बाद लोग बस उनका उपयोग करना बंद कर देंगे। न केवल डेटा बदल सकता है, बल्कि सेवा नीचे भी हो सकती है। मेरी राय में, यह प्रश्नों के लिए कोई परीक्षण नहीं है, और मुद्दों को खोजने के लिए एकीकरण / प्रणाली परीक्षणों पर निर्भर है। उस ने कहा, यदि एपीआई डेटा शायद ही कभी बदलता है और एपीआई ही लगभग हमेशा ऊपर है, तो यह एक व्यवहार्य विकल्प हो सकता है। अधिकांश API इस विवरण में फिट नहीं होते हैं।

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


तो मूल रूप से, आप बता रहे हैं कि यूनिट परीक्षण (# 1) और एकीकरण परीक्षण (# 2) हानिकारक हैं? जबकि # 3 उनमें से सबसे अच्छा लग सकता है यह सबसे महंगा भी हो सकता है। हर बार एपीआई में बदलाव होने पर इसे बनाए रखना पड़ता है। # 2 के बिना आपको वास्तविक API में संभावित बग-परिवर्तनों के बारे में पता नहीं चलेगा, जब तक कि आप उत्पादन में नहीं हैं (उपाय करने में बहुत देर हो चुकी है)। ठीक है, # 1 बिना वजह लगता है क्योंकि परीक्षण करने के लिए कोड की लाइनें नहीं हैं ... आज ... कल, कैसे पता है ...
Laiv

मैं कह रहा हूं कि खराब परीक्षण हानिकारक हैं, निश्चित रूप से। परतदार परीक्षण बहुत समय और प्रयास बर्बाद करते हैं, और लोगों को समग्र रूप से इकाई परीक्षणों में विश्वास खो देते हैं। कार्यान्वयन परिवर्तन (# 1) या केवल यादृच्छिक रूप से जब डेटा परिवर्तन (# 2) के साथ विराम होता है तो अच्छे परीक्षण नहीं होते हैं।
मीकल टेनबर्ग

एकीकरण परीक्षण डेटा का परीक्षण नहीं करते हैं। बस। वे परीक्षण को नहीं तोड़ सकते, बस एकीकरण को मान्य करते हैं। परीक्षण विश्वास का विषय नहीं है, अच्छी आदतें हैं जो अनुप्रयोग में मूल्य जोड़ते हैं
Laiv
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.