आप सब कुछ के लिए जवाब देंगे! डेवलपर की आंखों के माध्यम से उपभोक्ता प्रेरित अनुबंध

इस लेख में, हम उन समस्याओं के बारे में बात करेंगे जो उपभोक्ता प्रवृत्त संविदा हल करती हैं, और यह दिखाती हैं कि Node.js और स्प्रिंग बूट के साथ Pact के उदाहरण का उपयोग करके इसे कैसे लागू किया जाए। और इस दृष्टिकोण की सीमाओं के बारे में बात करते हैं।

समस्याओं

उत्पादों का परीक्षण करते समय, परिदृश्य परीक्षणों का अक्सर उपयोग किया जाता है जिसमें विशेष रूप से चयनित वातावरण में सिस्टम के विभिन्न घटकों के एकीकरण की जाँच की जाती है। लाइव सेवाओं पर इस तरह के परीक्षण सबसे विश्वसनीय परिणाम देते हैं (लड़ाई में परीक्षण की गिनती नहीं)। लेकिन एक ही समय में, वे सबसे महंगे में से एक हैं।

• यह अक्सर गलती से माना जाता है कि एकीकरण का वातावरण दोष सहिष्णु नहीं होना चाहिए। एसएलए, इस तरह के वातावरण के लिए गारंटी देता है शायद ही कभी बात की जाती है, लेकिन अगर यह उपलब्ध नहीं है, तो टीमों को या तो देरी से रिलीज करना होगा, या सर्वश्रेष्ठ के लिए आशा करनी चाहिए और बिना परीक्षण के लड़ाई में उतरना होगा। हालांकि सभी जानते हैं कि आशा कोई रणनीति नहीं है । और newfangled अवसंरचना प्रौद्योगिकियां केवल एकीकरण के वातावरण के साथ काम को जटिल बनाती हैं।
• एक और दर्द परीक्षण डेटा के साथ काम कर रहा है । कई परिदृश्यों को सिस्टम की एक निश्चित स्थिति की आवश्यकता होती है, जुड़नार। डेटा का मुकाबला करने के लिए उन्हें कितना करीब होना चाहिए? परीक्षण से पहले तारीख तक लाने और पूरा होने के बाद साफ करने के लिए कैसे?
• टेस्ट बहुत अस्थिर हैं । और न केवल उस बुनियादी ढांचे के कारण जिसका हमने पहले पैराग्राफ में उल्लेख किया था। परीक्षण विफल हो सकता है क्योंकि एक पड़ोसी टीम ने अपने स्वयं के चेक लॉन्च किए हैं जो सिस्टम की अपेक्षित स्थिति को तोड़ते हैं! कई झूठी नकारात्मक जाँच, परतदार परीक्षण @Ignored पर अपना जीवन समाप्त करते हैं। इसके अलावा, एकीकरण के विभिन्न भागों को अलग-अलग टीमों द्वारा समर्थित किया जा सकता है। उन्होंने त्रुटियों के साथ एक नया रिलीज उम्मीदवार उतारा - उन्होंने सभी उपभोक्ताओं को तोड़ दिया। कोई व्यक्ति इस समस्या को समर्पित परीक्षण छोरों के साथ हल करता है। लेकिन समर्थन की लागत को गुणा करने की कीमत पर।
• ऐसे परीक्षणों में बहुत समय लगता है । यहां तक ​​कि स्वचालन को ध्यान में रखते हुए, परिणाम घंटों के लिए अपेक्षित हो सकते हैं।
• और इसे बंद करने के लिए, यदि परीक्षण वास्तव में सही हो गया है, तो यह समस्या के कारण का तुरंत पता लगाने के लिए हमेशा संभव है। यह एकीकरण की परतों के पीछे गहरे छिप सकता है। या यह कई सिस्टम घटकों के राज्यों के अप्रत्याशित संयोजन का परिणाम हो सकता है।

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

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

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

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

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

इसके अलावा, प्रलेखन आमतौर पर नीचे की ओर बढ़ता है - ग्राहक सेवाओं के चश्मे का उपयोग करते हैं (इस मामले में, एक अन्य सेवा सेवा का ग्राहक हो सकता है)। यह व्यक्त नहीं करता है कि उपभोक्ता डेटा का उपयोग कैसे करते हैं, डेटा की क्या आवश्यकता है, वे उस डेटा के लिए क्या धारणा बनाते हैं। इस अज्ञानता का परिणाम हीरम का नियम है ।



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

कंज्यूमर ड्रिवेन कॉन्ट्रैक्ट्स के इस्तेमाल से कुछ हद तक इन समस्याओं को हल किया जा सकता है। किसी भी दृष्टिकोण और उपकरण की तरह, इसमें प्रयोज्यता और लागत की एक सीमा होती है, जिस पर हम भी विचार करेंगे। इस दृष्टिकोण के कार्यान्वयन से उनकी परियोजनाओं पर प्रयास करने के लिए परिपक्वता का पर्याप्त स्तर पहुंच गया है।

सीडीसी क्या है?

तीन प्रमुख तत्व:

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

इस प्रकार, अनुबंध निष्पादन योग्य है। और दृष्टिकोण की मुख्य विशेषता यह है कि एपीआई के व्यवहार की आवश्यकताएं क्लाइंट से सर्वर तक जाती हैं।

अनुबंध उस व्यवहार पर केंद्रित है जो वास्तव में उपभोक्ता के लिए मायने रखता है। एपीआई के बारे में अपनी मान्यताओं को स्पष्ट करता है।

सीडीसी का मुख्य लक्ष्य अपने डेवलपर्स और अपने ग्राहकों के डेवलपर्स के लिए एपीआई व्यवहार की समझ लाना है। यह दृष्टिकोण अच्छी तरह से BDD के साथ संयुक्त है, तीन अमीगो की बैठकों में आप अनुबंध के लिए खाली स्केच कर सकते हैं। अंततः, यह अनुबंध संचार को बेहतर बनाने का काम भी करता है; समस्या क्षेत्र की एक आम समझ साझा करना और टीमों के भीतर और बीच के समाधान को लागू करना।

संधि

CD, Pact से एक उदाहरण के रूप में इसके कार्यान्वयन में से एक का उपयोग करने पर विचार करें। मान लीजिए हम सम्मेलन के प्रतिभागियों के लिए एक वेब एप्लिकेशन बनाते हैं। अगले पुनरावृत्ति में, टीम एक प्रस्तुति अनुसूची विकसित करती है - अब तक वोटिंग या नोट्स जैसी किसी भी कहानी के बिना, केवल रिपोर्ट ग्रिड का उत्पादन। उदाहरण के लिए स्रोत कोड यहाँ है ।

तीन चार अमीगो की एक बैठक में एक उत्पाद, एक परीक्षक, बैकएंड के डेवलपर्स और एक मोबाइल एप्लिकेशन मिलते हैं। वे कहते हैं कि

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

 { "talks":[ { "title":"      ", "speakers":[ { "name":" " } ], "time":"2019-05-27T12:00:00+03:00" } ] } 

जिसके बाद फ्रंटएंड डेवलपर क्लाइंट कोड (फ्रंटएंड के लिए बैकेंड) लिखने के लिए जाता है। वह परियोजना में एक संविदा अनुबंध पुस्तकालय स्थापित करता है:

 yarn add --dev @pact-foundation/pact 

और एक परीक्षण लिखना शुरू करता है। यह स्थानीय स्टब सर्वर को कॉन्फ़िगर करता है, जो रिपोर्ट शेड्यूल के साथ सेवा का अनुकरण करेगा:

 const provider = new Pact({ //      consumer: "schedule-consumer", provider: "schedule-producer", // ,     port: pactServerPort, //  pact     log: path.resolve(process.cwd(), "logs", "pact.log"), // ,     dir: path.resolve(process.cwd(), "pacts"), logLevel: "WARN", //  DSL  spec: 2 }); 

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

 provider.setup().then(() => provider .addInteraction({ uponReceiving: "a request for schedule", withRequest: { method: "GET", path: "/schedule" }, willRespondWith: { status: 200, headers: { "Content-Type": "application/json;charset=UTF-8" }, body: { talks: [ { title: "      ", speakers: [ { name: " " } ], time: "2019-05-27T12:00:00+03:00" } ] } } }) .then(() => done()) ); 

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

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

 it("fetches schedule", done => { fetch(`http://localhost:${pactServerPort}/schedule`) .then(response => response.json()) .then(json => expect(json).toStrictEqual({ talks: [ { title: "      ", speakers: [ { name: " " } ], time: "2019-05-27T12:00:00+03:00" } ] })) .then(() => done()); }); 

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

परीक्षण चलाने के दौरान, संधि पुष्टि करती है कि ठूंठ को परीक्षणों में निर्दिष्ट अनुरोध प्राप्त हुआ था। विसंगतियों को pact.log फ़ाइल में भिन्न रूप में देखा जा सकता है।

 E, [2019-05-21T01:01:55.810194 #78394] ERROR -- : Diff with interaction: "a request for schedule" Diff -------------------------------------- Key: - is expected + is actual Matching keys and values are not shown { "headers": { - "Accept": "application/json" + "Accept": "*/*" } } Description of differences -------------------------------------- * Expected "application/json" but got "*/*" at $.headers.Accept 

यदि परीक्षण सफल होता है, तो JSON प्रारूप में एक अनुबंध उत्पन्न होता है। यह एपीआई के अपेक्षित व्यवहार का वर्णन करता है।

 { "consumer": { "name": "schedule-consumer" }, "provider": { "name": "schedule-producer" }, "interactions": [ { "description": "a request for schedule", "request": { "method": "GET", "path": "/schedule", "headers": { "Accept": "application/json" } }, "response": { "status": 200, "headers": { "Content-Type": "application/json;charset=UTF-8" }, "body": { "talks":[ { "title":"      ", "speakers":[ { "name":" " } ], "time":"2019-05-27T12:00:00+03:00" } ] }}} ], "metadata": { "pactSpecification": { "version": "2.0.0" } } } 

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

मान लीजिए, हमारे उदाहरण में, बैकएंड डेवलपर सेवा के निर्माण के लिए ग्रैडल का उपयोग करता है। यह निम्नलिखित निर्भरता को जोड़ता है:

 buildscript { // ... dependencies { classpath "org.springframework.cloud:spring-cloud-contract-pact:2.1.1.RELEASE" } } plugins { id "org.springframework.cloud.contract" version "2.1.1.RELEASE" // ... } // ... dependencies { // ... testImplementation 'org.springframework.cloud:spring-cloud-starter-contract-verifier' } 

और यह फ्रैटेन्डर से प्राप्त संधि अनुबंध को src/test/resources/contracts निर्देशिका में डालता है।

डिफ़ॉल्ट रूप से, स्प्रिंग-क्लाउड-कॉन्ट्रैक्ट प्लगइन अनुबंधों को घटाता है। असेंबली के दौरान, जेनरेटक्रेक्टटेस्ट्स ग्रेडल टास्क को अंजाम दिया जाता है, जो बिल्ड / जेनरेट किए गए टेस्ट-सोर्स डायरेक्टरी में निम्न टेस्ट जेनरेट करता है।

 public class ContractVerifierTest extends ContractsBaseTest { @Test public void validate_aggregator_client_aggregator_service() throws Exception { // given: MockMvcRequestSpecification request = given() .header("Accept", "application/json"); // when: ResponseOptions response = given().spec(request) .get("/scheduler"); // then: assertThat(response.statusCode()).isEqualTo(200); assertThat(response.header("Content-Type")).isEqualTo("application/json;charset=UTF-8"); // and: DocumentContext parsedJson = JsonPath.parse(response.getBody().asString()); assertThatJson(parsedJson).array("['talks']").array("['speakers']").contains("['name']").isEqualTo( /*...*/ ); assertThatJson(parsedJson).array("['talks']").contains("['time']").isEqualTo( /*...*/ ); assertThatJson(parsedJson).array("['talks']").contains("['title']").isEqualTo( /*...*/ ); } } 

इस परीक्षण को शुरू करते समय, हम एक त्रुटि देखेंगे:

 java.lang.IllegalStateException: You haven't configured a MockMVC instance. You can do this statically 

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

 public abstract class ContractsBaseTest { private ScheduleController scheduleController = new ScheduleController(); @Before public void setup() { RestAssuredMockMvc.standaloneSetup(scheduleController); } } 

पीढ़ी के दौरान इस बेस क्लास का उपयोग करने के लिए, आपको स्प्रिंग-क्लाउड-कॉन्ट्रैक्ट ग्रेडल प्लगइन को कॉन्फ़िगर करना होगा।

 contracts { baseClassForTests = 'ru.example.schedule.ContractsBaseTest' } 

अब हमारे पास निम्नलिखित परीक्षाएं हैं:

 public class ContractVerifierTest extends ContractsBaseTest { @Test public void validate_aggregator_client_aggregator_service() throws Exception { // ... } } 

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

सेवा डेवलपर अनुबंध के माध्यम से जानता है कि उसे क्या करना है, क्या व्यवहार लागू करना है।

संधि को विकास प्रक्रिया में गहराई से एकीकृत किया जा सकता है। आप एक ऐसे पैक्ट-ब्रोकर को तैनात कर सकते हैं जो इस तरह के अनुबंधों को एकत्रित करता है, उनके संस्करण का समर्थन करता है, और एक निर्भरता ग्राफ प्रदर्शित कर सकता है।



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

सीडीसी प्रयोज्यता

उपभोक्ता प्रवृत्त संविदा की सीमाएँ क्या हैं?

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

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

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

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

निष्कर्ष

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

इसी समय, सीडीसी टूल और फ्रेमवर्क सक्रिय रूप से विकसित हो रहे हैं और पहले से ही आपकी परियोजनाओं पर परीक्षण के लिए परिपक्वता तक पहुंच चुके हैं। टेस्ट :)

27-28 मई को क्वालकॉन्फ़ सम्मेलन में, आंद्रेई मार्केलोव ठेस पर परीक्षण तकनीकों के बारे में बात करेंगे , और आर्थर खिन्टेलसेव एक अत्यधिक भरी हुई फ्रंट-एंड की निगरानी के बारे में बात करेंगे, जब एक छोटी सी त्रुटि की कीमत भी दसियों हज़ार उदास उपयोगकर्ताओं की है।

गुणवत्ता के लिए चैट करें!