मैं आखिरकार सुसंगत सेवा के खिलाफ परीक्षण कैसे लिखूं?

Question

मैं Google App Engine Datastore के शीर्ष पर एक सेवा का निर्माण कर रहा हूं, जो अंततः एक सुसंगत डेटा स्टोर है। मेरे आवेदन के लिए, यह ठीक है।

हालाँकि, मैं ऐसे परीक्षण विकसित कर रहा हूँ जो PUT ऑब्जेक्ट और फिर GET ऑब्जेक्ट और रिटर्न ऑब्जेक्ट पर गुणों की जाँच जैसे काम करते हैं। दुर्भाग्य से, क्योंकि डेटास्टोर अंततः सुसंगत है, ये सरल परीक्षण प्रतिलिपि प्रस्तुत करने योग्य नहीं हैं।

आप अंततः सुसंगत सेवा का परीक्षण कैसे करते हैं?

Comments

आप पहले स्थान पर किसी बाहरी सेवा के खिलाफ प्रतिलिपि प्रस्तुत करने की अपेक्षा क्यों कर रहे हैं?

... और क्या आप वास्तव में परीक्षण करने की कोशिश कर रहे हैं? तुम्हारा कोड? या Google का?

मैं पूरे सिस्टम का परीक्षण कर रहा हूं। यानी, वे एकीकरण परीक्षण हैं, इकाई परीक्षण नहीं।

— डग रिचर्डसन

How can I reproducibly test an eventually consistent service? - तुम नहीं हो। आपको "reproducibly" या "अंततः" शब्द को हटाना होगा; आपके पास दोनों नहीं हो सकते।

— रॉबर्ट हार्वे

यदि यह अंततः सुसंगत है, तो प्रजनन योग्य है या नहीं, कोई भी परिणाम एक सफल होने वाला है। आपने पहले ही कहा कि यह आपके ऐप के लिए ठीक है, तो आप वास्तव में क्या परीक्षण कर रहे हैं? घटना? जीएई के साथ एकीकरण? तुम्हारा कोड?

— लाईव

Answer 1

अपने कार्यात्मक परीक्षणों को डिज़ाइन करते समय गैर-कार्यात्मक आवश्यकताओं पर विचार करें - यदि आपकी सेवा में "x (सेकंड / मिनट / आदि) के अनुरूप" की गैर-कार्यात्मक आवश्यकता है, तो बस PUT अनुरोधों को चलाएँ, x को प्रतीक्षा करें, फिर GET अनुरोध चलाएँ।

उस बिंदु पर, यदि डेटा अभी तक 'नहीं' आया है, तो आप PUT अनुरोध को अपनी आवश्यकताओं के अनुसार गैर-अनुरूप मान सकते हैं।

Answer 2

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

एक नकली सेवा बनाएं जो PUT और GET अनुरोधों को संभालती है, लेकिन इसे सुसंगत बनाने के लिए एक अतिरिक्त ऑपरेशन है। आपका परीक्षण तब है:

datastore.do_put(myobj);
datastore.make_consistent();
validate(datastore.do_get(), myobj);

यह आपको अपने सॉफ़्टवेयर के व्यवहार का परीक्षण करने की अनुमति देता है जब GET सफलतापूर्वक PUT ऑब्जेक्ट को पुनः प्राप्त करता है। यह आपको अपने सॉफ़्टवेयर के व्यवहार का परीक्षण करने की भी अनुमति देता है जब सेवा के अनुरूप नहीं होने के कारण GET को ऑब्जेक्ट (या सही ऑब्जेक्ट) नहीं मिलता है। बस कॉल करने के लिए बाहर छोड़ दें make_consistent()।

यह अभी भी परीक्षण करने के लायक है जो वास्तविक सेवा के साथ बातचीत करते हैं, लेकिन उन्हें आपके सामान्य विकास वर्कफ़्लो के बाहर चलना चाहिए, क्योंकि वे कभी भी 100% विश्वसनीय नहीं होंगे (जैसे यदि सेवा नीचे है)। इन परीक्षणों का उपयोग किया जाना चाहिए:

1. एक PUT और बाद में लगातार हो रहे GET के बीच औसत और सबसे खराब स्थिति के समय पर मैट्रिक्स प्रदान करें; तथा
2. सत्यापित करें कि आपकी नकली सेवा वास्तविक सेवा के समान व्यवहार करती है। Https://codewithoutrules.com/2016/07/31/verified-fakes/ देखें

Answer 3

ठीक है तो। "व्हाट आर आर यू टेस्टिंग" प्रमुख प्रश्न है।

• मैं अपने आंतरिक तर्क का परीक्षण कर रहा हूं कि Google सामग्री के काम करने पर क्या होता है

इस मामले में आपको Google सेवाओं का मज़ाक उड़ाना चाहिए और हमेशा प्रतिक्रिया देना चाहिए।

• मैं अपने तर्क का परीक्षण कर रहा हूं कि मैं उन क्षणिक त्रुटियों का सामना कर सकता हूं जिन्हें मैं जानता हूं कि Google उत्पादन करेगा

इस मामले में आपको Google सेवाओं का मजाक उड़ाना चाहिए और हमेशा सही प्रतिक्रिया से पहले क्षणिक त्रुटि को वापस करना चाहिए

• मैं परीक्षण कर रहा हूं कि मेरा उत्पाद वास्तव में वास्तविक Google सेवा के साथ काम करेगा

आपको वास्तविक Google सेवाओं को इंजेक्ट करना चाहिए और परीक्षण चलाना चाहिए। परंतु! जिस कोड का आप परीक्षण कर रहे हैं, उसमें निर्मित क्षणिक त्रुटि हैंडलिंग (पुनर्प्रयास) होनी चाहिए। तो आपको लगातार प्रतिक्रिया मिलनी चाहिए। (जब तक कि Google बहुत बुरी तरह से व्यवहार नहीं किया जाता)

Comments

मॉक सुझाव के लिए +1 - यदि मैं कर सकता था तो अतिरिक्त विकल्पों के लिए मैं अधिक वोट दूंगा।

— 5

Answer 4

निम्नलिखित में से किसी एक का उपयोग करें:

• PUT के बाद, G N N को सफलता मिलने तक पुनः प्रयास करें। यदि N की कोशिश के बाद कोई सफलता नहीं मिलती है।
• PUT और GET के बीच सोएं

दुर्भाग्य से, आपको इन दोनों तकनीकों के लिए जादुई मूल्यों (एन या नींद की अवधि) को चुनना होगा।

Comments

क्या आप स्पष्ट कर सकते हैं: ये विकल्प हैं, या पूरक? मुझे लगता है कि आपके कहने का मतलब है कि वे विकल्प हैं - और यही मैं उनके बारे में सोचता हूं। लेकिन शायद मैं गलत हूं।

— रॉबिन ग्रीन

सही है, मेरा मतलब था कि वे विकल्प होंगे।

— डग रिचर्डसन

Answer 5

जैसा कि मैंने इसे समझा, Google क्लाउड डेटास्टोर दोनों को दृढ़ता से और अंततः सुसंगत प्रश्नों की अनुमति देता है ।

व्यापार बंद यह है कि दृढ़ता से सुसंगत प्रश्न बहुत गंभीर रूप से सीमित हैं (कुछ आप परीक्षण के दौरान साथ रह सकते हैं)।

एक संभावना एक रैपर के भीतर डेटस्टोर में अपने प्रश्नों को रखने की हो सकती है जो परीक्षण उद्देश्यों के लिए मजबूत स्थिरता को सक्षम कर सकते हैं।

उदाहरण के लिए, आपके पास बुलाया तरीके start_debug_strong_consistency()और हो सकते हैंend_debug_strong_consistency() ।

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

आपके द्वारा परीक्षण किए जा रहे वास्तविक प्रश्नों का एकमात्र परिवर्तन कॉल करना होगा setAncestor(your_debug_key)यदि वह कुंजी मौजूद है।

Answer 6

एक दृष्टिकोण है, जो सिद्धांत में अच्छा है, लेकिन हमेशा व्यावहारिक नहीं हो सकता है, परीक्षण के अंतर्गत सिस्टम में सभी लिखने संचालन सुनिश्चित करने के लिए है idempotent । इसका मतलब है, एक निश्चित अनुक्रमिक क्रम में अपने परीक्षण कोड की चीजों को मानते हुए, आप सभी पढ़ सकते हैं और सभी व्यक्तिगत रूप से लिख सकते हैं जब तक कि आप अपेक्षित परिणाम प्राप्त नहीं करते हैं, तब तक कुछ समय तक पुन: प्रयास करते रहें जो आप परीक्षण कोड में परिभाषित करते हैं। यही है, बात A1 करें, यदि परिणाम B1 तक आवश्यक हो तो पुनः प्रयास करें, फिर बात A2 करें, यदि आवश्यक हो तो परिणाम 2 या 2 तक पुन: प्रयास करें, और इसी तरह।

फिर आपको लिखने के संचालन की पूर्व शर्त के लिए जाँच करने के लिए परेशान करने की आवश्यकता नहीं है, क्योंकि लिखने के संचालन पहले से ही आपके लिए उन्हें जाँच रहे हैं, और आप बस उन्हें पुनः प्रयास करें जब तक वे सफल नहीं हो जाते!

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

Answer 7

Google App Engine Datastore जैसी सेवा कई वैश्विक स्तर पर मौजूद उपस्थिति (POP) के डेटा प्रतिकृति पर आधारित है। अंततः सुसंगत सेवा के लिए कोई भी एकीकरण परीक्षण वास्तव में पीओपी के अपने सेट में उस सेवा की प्रतिकृति की दर का परीक्षण है। किसी दी गई सेवा में प्रत्येक पीओपी के लिए सामग्री जिस दर पर फैली हुई है, वह कई कारकों के आधार पर सेवा के भीतर प्रत्येक पीओपी के समान नहीं होती है, जैसे कि प्रतिकृति की विधि और विभिन्न इंटरनेट परिवहन मुद्दे - ये दो उदाहरण हैं किसी भी अंततः सुसंगत डेटास्टोर सेवा में अधिकांश रिपोर्टों के लिए कौन खाता है (कम से कम यह मेरा अनुभव था जब मैं एक प्रमुख सीडीएन के लिए काम कर रहा था)।

किसी दिए गए प्लेटफ़ॉर्म पर किसी ऑब्जेक्ट की प्रतिकृति को प्रभावी ढंग से जांचने के लिए, आपको विशेष रूप से सेवा के प्रत्येक POP से उसी हाल ही में रखी गई वस्तु का अनुरोध करने के लिए परीक्षण सेट करना होगा। मैं सुझाव दे रहा हूं कि पीओपी सूची का परीक्षण एक से पांच बार या जब तक आपके पीओपी सूची के सभी पीओपी में वस्तु नहीं है। यहाँ अंतराल का एक सेट है जिस पर परीक्षण करने के लिए जिसे आप समायोजित करने के लिए स्वतंत्र हैं: १, ५, ६० मिनट, १२ घंटे, २५ घंटे बाद डेटास्टर पर रखने के बाद। कुंजी बाद में समीक्षा और विश्लेषण के लिए प्रत्येक अंतराल पर परिणामों को लॉग कर रही है ताकि विश्व स्तर पर वस्तुओं को दोहराने के लिए किसी सेवा की क्षमता के लिए एक महसूस हो सके। अक्सर डेटास्टोर सेवाएं केवल एक स्थानीय कॉपी को पीओपी में खींचती हैं, एक बार स्थानीय रूप से अनुरोध किया गया है [बीजीपी प्रोटोकॉल के माध्यम से मार्ग किया जाता है, यही वजह है कि आपके परीक्षण को प्रत्येक विशिष्ट पीओपी से वस्तु का अनुरोध करना पड़ता है क्योंकि यह किसी दिए गए प्लेटफॉर्म के लिए विश्व स्तर पर मान्य है] । Google के डेटास्टोर के मामले में आप किसी दिए गए ऑब्जेक्ट को "33% से अधिक उपस्थिति के 70 से अधिक बिंदुओं" से क्वेरी करने के लिए अपना परीक्षण स्थापित करने के लिए देख रहे होंगे; आपको Google समर्थन से POP विशिष्ट पता url सूची प्राप्त करने की संभावना होगी [Ref:https://cloud.google.com/about/locations/ ] या यदि Google तेज़ी से प्रतिकृति के लिए उपयोग कर रहा है, तो Fastly समर्थन [ https://www.fastly.com/resources ]।

इस विधि के कुछ फायदे: 1) आपको किसी दिए गए सेवा के प्रतिकृति मंच के लिए एक महसूस होगा, इसके स्ट्रैंथ और कमजोरियों को वैश्विक स्तर पर समग्र रूप से जान लें [जैसा कि यह एकीकरण परीक्षण के दौरान था]। 2) जो भी वस्तु आप परीक्षण करते हैं उसके लिए आपके पास गर्म सामग्री के लिए एक उपकरण उपलब्ध होगा [वह पहला अनुरोध करें जो किसी दिए गए स्थानीय पीओपी में प्रतिलिपि बनाता है] - इस प्रकार आपको यह सुनिश्चित करने का एक तरीका प्रदान करता है कि आपके ग्राहकों के अनुरोध से पहले सामग्री विश्व स्तर पर फैली हो। धरती पर कहीं भी

Answer 8

मुझे Google App Engine Datastore के साथ अनुभव है। स्थानीय स्तर पर, आश्चर्यजनक रूप से, यह अक्सर "सुसंगत" की तुलना में अधिक "अंततः" होता है। सबसे सरल उदाहरण: एक नई इकाई बनाएँ, और फिर इसे पुनः प्राप्त करें। पिछले 5 वर्षों में कई बार, मैंने देखा है कि स्थानीय स्तर पर चलने वाली एसडीके को तुरंत नई इकाई नहीं मिल रही है, लेकिन लगभग आधे सेकंड के बाद इसे खोजें।

हालांकि, वास्तविक Google सर्वर के खिलाफ चल रहा है, मैंने उस व्यवहार को नहीं देखा है। वे आपके डेटास्टोर क्लाइंट को हमेशा उसी सर्वर पर उनके पक्ष में चलाने का प्रयास करते हैं, इसलिए आमतौर पर किसी भी परिवर्तन को तुरंत प्रश्नों में परिलक्षित किया जाता है।

एकीकरण परीक्षणों के लिए मेरी सलाह उन्हें असली सर्वरों के खिलाफ चलाने की है, और फिर आपको अपने परिणाम प्राप्त करने के लिए संभवतः कोई नकली मतदान या देरी करने की आवश्यकता नहीं होगी।

Comments

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

— रोबिन ग्रीन