01 दिस॰ 2025·8 मिनट
चैट-जनित ऐप्स का परीक्षण: पहले क्या टेस्ट करें और क्या छोड़ें
React, Go API और Flutter में चैट-जनित ऐप्स के लिए प्राथमिकता वाला टेस्ट प्लान: न्यूनतम यूनिट, इंटीग्रेशन और e2e चेक जो अधिकांश रिग्रेशन्स पकड़ लेते हैं।
React, Go API और Flutter में चैट-जनित ऐप्स के लिए प्राथमिकता वाला टेस्ट प्लान: न्यूनतम यूनिट, इंटीग्रेशन और e2e चेक जो अधिकांश रिग्रेशन्स पकड़ लेते हैं।
चैट से बने कोडबेस अक्सर उन्हीं जगहों पर फेल होते हैं क्योंकि कोड सही दिखने वाले टुकड़ों से जुदा-जुदा बनता है जिन्हें एक-दूसरे के साथ सच में मिलने का दबाव नहीं मिला होता। ज़्यादातर फीचर हैप्पी पाथ पर काम करते हैं, पर असली यूज़र्स जब तेज़ी से क्लिक करें, अजीब इनपुट भेजें, या क्लाइंट का पुराना वर्शन इस्तेमाल करें तो टूट जाते हैं।
जोखिम का बड़ा हिस्सा glue code में होता है: वे छोटे-छोटे हिस्से जो स्क्रीन को API कॉल से जोड़ते हैं, APIレス्पॉन्स को UI स्टेट में मैप करते हैं, और यूज़र इनपुट को डेटाबेस राइट्स में बदलते हैं। ये हिस्से बोरिंग होते हैं, इसलिए उन्हें कम ध्यान मिलता है—फिर भी ये पूरे ऐप के फ्लो को नियंत्रित करते हैं।
रेग्रेशन्स उन बिंदुओं के इर्द-गिर्द clustered होते हैं जहाँ दो कंपोनेंट्स को एक कॉन्ट्रैक्ट शेयर करना होता है। UI एक शेप की उम्मीद करता है, API कुछ और भेज देता है। API मानता है कि DB कोई वैल्यू स्वीकार करेगा, फिर कोई constraint उसे रिजेक्ट कर देता है। या एक लेयर ने नाम, टाइप, या डिफ़ॉल्ट बदले और दूसरे फ़ॉलो नहीं करते।
वही फेल्योर पॉइंट बार-बार दिखते हैं:
तेज़ी इसे और तेज़ कर देती है। प्लेटफॉर्म्स जैसे Koder.ai त्वरित इटरेशन को प्रोत्साहित करते हैं: आप प्रॉम्प्ट दे देते हैं, पुनर्जेनरेट करते हैं, रीफ़ैक्टर करते हैं और आगे बढ़ते हैं। यह ताकत है। लेकिन इसका मतलब यह भी है कि छोटे बदलाव अक्सर होते हैं और boundary टूटने की संभावना बढ़ जाती है। जब आप तेज़ी से शिप करते हैं, तो आपको ऐसे टेस्ट चाहिए जो तेज़ चलें और जोरदार तरीके से फेल हों।
लक्ष्य कॉन्फिडेंस है, परफेक्शन नहीं। आप हर लाइन को सही साबित करने की कोशिश नहीं कर रहे। आप उन बदलावों को पकड़ने की कोशिश कर रहे हैं जो प्रोडक्शन में शर्मिंदगी पैदा कर दें: फ़ॉर्म जो अब सेव नहीं होता, API जो वैध अनुरोध रिजेक्ट करने लगा, या डेटाबेस अपडेट जो चुपचाप किसी फील्ड को लिखना बंद कर दे।
एक सरल अपेक्षा मदद करती है: पहले कॉन्ट्रैक्ट्स और टॉप यूज़र पाथ्स की रक्षा करें। बाकी सब तब तक रुका रह सकता है जब तक वह साबित न करें कि इससे नुकसान हो रहा है।
चैट-जनित कोड के साथ बड़ा रिस्क आमतौर पर कंपाइल होने का नहीं होता। असली बात यह है कि छोटे बदलाव उस व्यवहार को तोड़ देते हैं जो आपने स्पष्ट माना था।
शुरूआत में अपने टॉप रिस्क्स को साधारण भाषा में नाम दें। अगर किसी बग का असर इन पर पड़े तो वह जल्दी महंगा हो जाता है:
फिर सबसे छोटा टेस्ट सेट चुनें जो असली यूज़र फ्लोज़ और उनके नीचे के API कॉन्ट्रैक्ट्स को कवर करे। एक अच्छा नियम: हर कोर फ्लो के लिए एक हैप्पी पाथ और एक “खराब इनपुट” केस। उदाहरण के लिए, “create item” को सफलता और एक वेलिडेशन फेलियर (मिसिंग रीक्वायर्ड फील्ड) दोनों टेस्ट करने चाहिए, क्योंकि प्रॉम्प्ट बदलते ही दोनों अक्सर टूटते हैं।
फिर तय करें कि मर्ज से पहले क्या पकड़ा जाना चाहिए बनाम रिलीज़ से पहले क्या। मर्ज से पहले टेस्ट तेज़ और भरोसेमंद होने चाहिए। रिलीज़ से पहले वाला सेट धीमा और व्यापक हो सकता है।
सरल प्राथमिकता पैमाना बहसें कम रखता है:
ठोस उदाहरण: React ऐप में “Change password” फीचर जिसको Go API और Flutter क्लाइंट दोनों सपोर्ट करते हों।
P0: API कमजोर पासवर्ड रिजेक्ट करे, API स्टोर किया हुआ हैश अपडेट करे, और दोनों क्लाइंट पर फेल होने पर एरर संदेश दिखे।
P1: रेट लिमिटिंग और सेशन एक्सपायरी।
P2: पिक्सल-परफेक्ट UI स्टेट्स।
अगर आप चैट-जनित ऐप्स टेस्ट कर रहे हैं (ऐसे प्रोजेक्ट्स भी जिनको Koder.ai जैसे टूल से बनाया गया है), तो यह 80/20 लेंस आपको दर्जनों भंगुर टेस्ट से बचाता है जो फिर भी उन विफलताओं को मिस करते हैं जो असली यूज़र्स महसूस करते हैं।
React रिग्रेशन्स ज़्यादातर दो जगहों से आते हैं: छोटे लॉजिक की गलतियाँ (डेटा शेपिंग, वेलिडेशन) और UI स्टेट जो रियलिटी से मैच नहीं करती (लोडिंग, एरर, डिसेबल्ड बटन)। जहां यूज़र को दर्द होता है वहां से शुरू करें।
अगर किसी फ़ंक्शन के इनपुट और आउटपुट स्पष्ट हैं, तो किसी UI से पहले उसे टेस्ट करें। ये टेस्ट तेज़ होते हैं, कम फ्लेकी होते हैं, और छोटे बदलावों से होने वाली बड़ी टूटन को रोकते हैं।
अच्छे शुरुआती लक्ष्य: डेट और करेंसी फॉर्मैटर्स, फ़ील्ड वेलिडेटर्स, APIレス्पॉन्स → व्यू मॉडल मैपर, और स्क्रीन चलाने वाले रिड्यूसर या स्टेट मशीन।
उसके बाद, उन स्क्रीन के लिए कुछ कंपोनेंट टेस्ट लिखें जिनका उपयोग लोग काम पूरा करने के लिए करते हैं। बहुत सारी शैलो स्नैपशॉट्स के बजाय कुछ ऐसे टेस्ट रखें जो उपयोगकर्ता की तरह काम करें: फ़ॉर्म में टाइप करें, बटन क्लिक करें, और यह असर्ट करें कि यूज़र क्या देखता है।
वे UI स्टेट्स पर फोकस करें जो अक्सर टूटते हैं: फ़ॉर्म वेलिडेशन और सबमिट बिहेवियर, डिसेबल्ड स्टेट्स (डबल-सबमिट रोकना शामिल), लोडिंग और रिट्राई, एरर रेंडरिंग, और empty बनाम results स्टेट।
जो भी नेटवर्क से बात करता है, boundary पर मॉक करें। अपने API क्लाइंट को सीमांत मानें: रिक्वेस्ट शेप (method, path, मुख्य क्वेरी पैरामीटर्स, और पेलोड) असर्ट करें, फिर कंपोनेंट को एक यथार्थवादी रिस्पॉन्स दें। यह कॉन्ट्रैक्ट ड्रिफ्ट जल्दी पकड़ता है, खासकर जब बैकएंड भी तेजी से जेनरेट या एडिट हो रहा हो।
एक नियम जो लगातार फायदा देता है: हर बार जब आप एक बग फिक्स करें तो एक टेस्ट जोड़ें जो उस बग के लौटने पर फेल हो। उदाहरण: अगर किसी Koder.ai-जनित पेज ने कभी userId भेजा था बजाय id के, तो एक टेस्ट जोड़ें जो आउटगोइंग पेलोड की कुंजीज़ वेरिफाई करे।
Go हैंडलर सही दिख सकते हैं जबकि अंदर छोटे लॉजिक गैप्स छुपे हों जो असली बग बन जाते हैं। सबसे तेज़ जीतें वे हैं जो इनपुट्स, परमिशन्स और उन नियमों को पिन कर देती हैं जो डेटा को म्यूटेट करते हैं।
रिक्वेस्ट वेलिडेशन से शुरू करें। चैट-जनित कोड खाली स्ट्रिंग्स स्वीकार कर सकता है, मैक्स लेंथ इग्नोर कर सकता है, या गलत डिफ़ॉल्ट लगा सकता है। हैंडलर (या उसके वेलिडेशन फ़ंक्शन) को बुरे पेलोड के साथ कॉल करने वाले टेस्ट लिखें और स्पष्ट 400 रिस्पॉन्स और उपयोगी एरर असर्ट करें।
इसके बाद, एज पर ऑथ और परमिशन्स लॉक करें। एक सामान्य रिग्रेशन है “ऑथ है, पर गलत रोल अभी भी अपडेट कर सकता है।” हैप्पी पाथ और कुछ फोर्बिडन केस टेस्ट करें, यूज़र कॉन्टेक्स्ट बनाकर और हैंडलर या मिडलवेयर को कॉल करके।
फिर उन बिज़नस रूल्स पर ध्यान दें जो डेटा म्यूटेट करते हैं। Create, update, delete और कोई भी idempotent एंडपॉइंट (जैसे “create if not exists”) कड़े टेस्ट के लायक हैं। ये वे जगहें हैं जहाँ छोटा रीफ़ैक्टर गलती से डुप्लीकेट्स होने दे सकता है, किसी जरूरी स्टेट ट्रांज़िशन को स्किप कर सकता है, या उन फील्ड्स को ओवरराइट कर सकता है जो immutable होने चाहिए।
एरर मैपिंग को स्पष्ट बनायें। आपकी API को सामान्य विफलताओं को सही स्टेटस कोड्स में लगातार ट्रांसलेट करना चाहिए: बुरा इनपुट (400), नहीं मिला (404), संघर्ष (409), और अनपेक्षित एरर (500). यूनिट टेस्ट दोनों—स्टेटस और एक स्थिर एरर शेप—को असर्ट करें ताकि क्लाइंट टूटें नहीं।
ऊपर जल्दी कवर करने वाले हाई-ROI चेक्स: रीक्वायर्ड फील्ड्स और डिफ़ॉल्ट, रोल-वार परमिशन चेक, idempotency, और सामान्य विफलताओं से स्टेटस कोड का साफ मैपिंग।
टेबल-ड्रिवन टेस्ट एज केस्स को पढ़ने योग्य रखते हैं:
tests := []struct{
name string
body string
wantStatus int
}{
{"missing name", `{"name":""}`, 400},
{"too long", `{"name":"aaaaaaaaaaaaaaaa"}`, 400},
}
Flutter बग्स चैट-जनित ऐप्स में अक्सर छोटे क्लाइंट-साइड अनुमान से आते हैं: कभी-कभी null होने वाला फ़ील्ड, अलग फॉर्मैट में आने वाली तारीख, या रीट्राई के बाद लोडिंग में फंस जाने वाली स्क्रीन। कुछ फोकस्ड टेस्ट इनका ज्यादातर हिस्सा पकड़ लेते हैं।
डेटा मैपिंग से शुरू करें। सबसे बड़ा रिस्क JSON और आपके Dart मॉडल्स की बाउंड्री है। असली दिखने वाले पेलोड fromJson में फीड करें और सुनिश्चित करें कि आप मिसिंग फील्ड्स, रीनेम किए गए कीज़, और अजीब वैल्यूज़ को हैंडल करते हैं। Enums और डेट्स आम दोषी हैं: नया enum वैल्यू ऐप क्रैश नहीं कराना चाहिए, और पार्सिंग सुरक्षित तरीके से फेल होनी चाहिए (स्पष्ट एरर के साथ) बजाय यह कि ग़लत वैल्यू silently बन जाए।
उसके बाद स्टेट ट्रांज़िशन्स टेस्ट करें। आप BLoC, Provider, Riverpod, या साधारण setState जो भी इस्तेमाल कर रहे हों—वे जो चीज़ें रोज़ यूज़र को टच करती हैं उन्हें लॉक करें: पहला लोड, रिफ्रेश, एरर, और रीट्राई। ये टेस्ट सस्ते हैं और “हमेशा घूमता रहा” समस्या जल्दी पकड़ लेते हैं।
एक छोटा सेट जो अक्सर फायदा देता है:
कॉनक्रिट उदाहरण: Koder.ai से बने “Create Project” स्क्रीन में प्रोजेक्ट नाम और region स्वीकार हो सकते हैं। यूनिट-टेस्ट करें कि ख़ाली नाम रोका जाता है, whitespace ट्रिम होता है, और API से आने वाला अनदेखा region वैल्यू ड्रॉपडाउन क्रैश न करे।
Golden UI टेस्ट मददगार हो सकते हैं, पर इन्हें कम रखें। सिर्फ कुछ स्थिर स्क्रीन के लिए उपयोग करें जहाँ लेआउट रिग्रेशन वास्तव में दर्द देता है—जैसे लॉगिन स्क्रीन, प्रमुख डैशबोर्ड, या क्रिटिकल चेकआउट/क्रिएट फ्लो।
जब आप चैट टूल्स से तेज़ी से बनाते हैं, सबसे दर्दनाक बग लेयर्स के बीच आते हैं: React पेज API को कॉल करता है, Go हैंडलर Postgres में लिखता है, और UI उस रिस्पॉन्स शेप पर अपेक्षा करता है जो बदल गई। इंटीग्रेशन टेस्ट क्रॉस-लेयर ब्रेक्स पकड़ने का सबसे तेज़ तरीका हैं बिना हर चीज़ को टेस्ट किए।
एक अच्छा नियम: हर कोर रिसोर्स (users, projects, orders आदि) के लिए एक असली Postgres-समर्थित पाथ end-to-end टेस्ट करें। नहीं हर एज केस—एक हैप्पी पाथ जो वायरिंग काम कर रही है यह साबित करे।
एक छोटे हाई-सिग्नल चेक्स सेट से शुरू करें:
इन टेस्ट्स के लिए रियल Postgres इंस्टेंस का उपयोग करें (अक्सर डिस्पोजेबल DB)। केवल वही सीड करें जिसकी ज़रूरत है, हर टेस्ट के बाद साफ़ करें, और असर्ट्स उन चीज़ों पर केंद्रित रखें जिन्हें यूज़र नोट करते हैं: सेव किया गया डेटा सही है, परमिशन्स लागू हैं, और क्लाइंट रिस्पॉन्स पार्स कर सकते हैं।
उदाहरण: “Create Project” फीचर। Go इंटीग्रेशन टेस्ट POST /projects हिट करता है, 201 रिस्पॉन्स जांचता है, फिर प्रोजेक्ट फ़ेच कर नाम और owner ID कन्फ़र्म करता है। React इंटीग्रेशन टेस्ट क्रिएट फ़ॉर्म सबमिट करता है और पुष्टि करता है कि सफलता स्टेट नया नाम दिखाती है। Flutter टेस्ट प्रोजेक्ट्स लिस्ट खोलता है, प्रोजेक्ट बनाता है, और रिफ्रेश के बाद यह दिखाई देता है।
अगर आप Koder.ai पर ऐप्स जेनरेट करते हैं, तो ये टेस्ट तब भी सुरक्षा देते हैं जब रीजनरेट किए गए UI या हैंडलर गलती से पेलोड शेप या एरर फॉर्मैट बदल दें।
E2E टेस्ट्स आपका "क्या ऐप एंड-टू-एंड काम करता है?" सुरक्षा जाल हैं। ये तब सबसे उपयोगी होते हैं जब वे छोटे और उबाऊ बने रहें: स्मोक टेस्ट्स जो यह साबित करें कि React, Go API, Postgres और Flutter के बीच वायरिंग बदलने के बाद भी बनी रहती है।
उन कुछ यात्राओं का ही चयन करें जिनका टूटना वाकई दर्ददेह होगा: साइन इन/आउट, रिकॉर्ड बनाना, एडिट और सेव करना, सर्च/फिल्टर और रिज़ल्ट खोलना, और चेकआउट/पेमेंट (यदि लागू हो)।
पहले एक ब्राउज़र और एक डिवाइस प्रोफ़ाइल पर चलाएँ (उदाहरण के लिए वेब के लिए Chrome और मोबाइल के लिए एक सामान्य फ़ोन साइज़). ग्राहकों की शिकायत मिलने पर ही और ब्राउज़र/डिवाइस जोड़ें।
स्थिरता एक फीचर है। टेस्ट्स को deterministic बनायें ताकि वे तभी फेल हों जब सच में कुछ टूटा हो:
E2E से मुख्य पाथ को मान्य करें, हर एज केस को नहीं। एज केस्स यूनिट और इंटीग्रेशन टेस्ट्स में होने चाहिए जहाँ वे सस्ते और कम नाजुक होते हैं।
सबसे तेज़ तरीका समय गँवाने का यह है कि आप ऐसे टेस्ट लिखें जो थोरही thorough दिखते हैं पर असल बग नहीं पकड़ते। एक छोटा, फोकस्ड सेट व्यापक जाल से बेहतर है जिस पर किसी का भरोसा न रहे।
स्नैपशॉट टेस्ट्स React और Flutter में एक आम जाल हैं। बड़े स्नैपशॉट्स बेकार कारणों से बदलते रहते हैं (कॉपी ट्वीक, लेआउट शिफ्ट, छोटे रीफ़ैक्टर), इसलिए टीमें या तो शोर भरी अपडेट स्वीकार कर लेती हैं या फेलियर्स को नोटिस करना बंद कर देती हैं। स्नैपशॉट्स सिर्फ़ बहुत छोटे, स्थिर सतह के लिए रखें—जैसे किसी छोटे फॉर्मैटर का आउटपुट, न कि पूरा स्क्रीन।
दूसरा छोड़ने योग्य: थर्ड-पार्टी लाइब्रेरीज़ का परीक्षण। आपको यह साबित करने की ज़रूरत नहीं कि React Router, कोई डेट पिकर, या HTTP क्लाइंट काम करता है। इसके बजाय अपने इंटीग्रेशन पॉइंट को टेस्ट करें: जहाँ आप इसे कॉन्फ़िगर करते हैं, इसमें डेटा मैप करते हैं, या इसकी एरर हैंडल करते हैं।
स्टाइलिंग टेस्ट्स शायद ही कभी लाभदायक होते हैं। व्यवहार चेक (फॉर्म अमान्य होने पर बटन डिसेबल, 401 पर एरर मैसेज दिखे) पिक्सल-लेवल आसेर्ट्स से बेहतर हैं। अपवाद तब बनाएं जब स्टाइलिंग व्यवहार या अनुपालन को प्रभावित करे: कंट्रास्ट की ज़रूरतें, कीबोर्ड उपयोगकर्ताओं के लिए फोकस आउटलाइन, या कोई महत्वपूर्ण उत्तरदायी लेआउट जो यूज़र की क्रिया बदल दे।
एक ही चेक को हर लेयर पर डुप्लिकेट करने से बचें। यदि आपने पहले से Go API इंटीग्रेशन टेस्ट में अस्वीकृत अनुरोधों के 401 लौटाने का असर्शन कर लिया है, तो शायद वही असर्शन यूनिट और e2e दोनों में दोहराने की ज़रूरत नहीं।
परफॉर्मेंस टेस्टिंग ज़रूर करें—बस बाद में। तब तक इंतजार करें जब तक आपका ऐप फ्लो स्थिर न हो, फिर एक-दो मापनीय लक्ष्य सेट करें और उन्हें लगातार ट्रैक करें।
मान लीजिए आप एक साधारण फीचर शिप करते हैं: साइन-इन यूज़र अपना प्रोफ़ाइल एडिट कर रहा है और ईमेल बदल रहा है। यह अच्छा कैनरी है क्योंकि यह UI स्टेट, API नियम और क्लाइंट कैशिंग सबको छूता है।
यहाँ वह न्यूनतम टेस्ट सेट है जो ज़्यादातर रिग्रेशन्स पकड़ लेता है बिना पूरा टेस्ट सूट बनाये:
updated_at) अपडेट होते हैं।यह सेट आम ब्रेकपॉइंट्स को लक्षित करता है: React में UI वेलिडेशन और डिसेबल्ड स्टेट्स, Go में नियमों का ड्रिफ्ट, और Flutter में stale या भ्रमित करने वाला UI। अगर आप Koder.ai जैसे प्लेटफ़ॉर्म से बनाते हैं जहाँ कोड जल्दी बदल सकता है, तो ये टेस्ट तेज़ सिग्नल देते हैं और रखरखाव कम रखते हैं।
60 मिनट के लिए टाइमर सेट करें और रिस्क पर ध्यान दें, परफेक्शन पर नहीं। चैट-जनित कोड सही दिख सकता है पर छोटे नियम, एज केस या लेयर्स के बीच वायरिंग छूट सकती है। आपका लक्ष्य एक छोटा टेस्ट सेट है जो व्यवहार बदलने पर जोरदार तरीके से फेल करे।
5 यूज़र एक्शन्स लिख दें जो हर बार काम करने चाहिए। इन्हें स्पष्ट रखें: “sign in”, “create an order”, “pay”, “see order history”, “reset password”. अगर आप Koder.ai पर बना रहे हैं, तो वे फ्लो चुनें जिन्हें आप आज एंड-टू-एंड डेमो कर सकते हैं—not जो आप बाद में जोड़ना चाहते हैं।
हर फ्लो के लिए वह एक नियम ढूंढें जो गलत होने पर असली नुकसान पहुंचायेगा। उस लेयर में एक फास्ट यूनिट टेस्ट जोड़ें जहाँ वह नियम रहता है:
उदाहरण: “Checkout को निगेटिव quantity की अनुमति नहीं देनी चाहिए।” इसे API में एक बार टेस्ट करें, और यदि UI भी इसे लागू करता है तो UI/क्लाइंट में भी एक बार टेस्ट करें।
हर फ्लो के लिए एक इंटीग्रेशन टेस्ट जोड़ें जो असली API को हिट करे और Postgres में असली डेटाबेस राइट करे। इसे संकुचित रखें: बनाएँ, अपडेट करें, फ़ेच करें, और स्टोर किए गए परिणाम की पुष्टि करें। यह वायरिंग मुद्दे जैसे गलत फील्ड नाम, मिसिंग ट्रांज़ैक्शन्स, या ब्रोकन माइग्रेशन्स पकड़ता है।
कुल 3–6 e2e फ्लोज चुनें। सबसे क्रॉस-लेयर पाथ्स चुनें (login → create → view)। स्थिर टेस्ट डेटा पर निर्णय लें (सीडेड यूज़र, ज्ञात IDs, फिक्स्ड क्लॉक) ताकि टेस्ट randomness पर निर्भर न हों।
CI में यह ऑर्डर चलायें: हर पुश पर यूनिट टेस्ट, हर पुश या main पर इंटीग्रेशन, और e2e केवल main पर या नाइटली जहाँ संभव हो।
गलत चीज़ को गलत स्तर पर टेस्ट करना समय बर्बाद करने का सबसे तेज़ तरीका है। अधिकांश फेल्यर अनुमानित होते हैं: अस्पष्ट कॉन्ट्रैक्ट्स, अवास्तविक मॉक, और ऐसा सूट जिस पर किसी का भरोसा नहीं।
एक आम गलती है API कॉन्ट्रैक्ट पर सहमति से पहले टेस्ट शुरू करना। अगर Go API एरर कोड, फील्ड नाम, या pagination नियम बदलता है, तो React और Flutter क्लाइंट ऐसे तरीकों से फेल होंगे जो रैंडम दिखते हैं। पहले कॉन्ट्रैक्ट लिखें (रिक्वेस्ट, रिस्पॉन्स, स्टेटस कोड, एरर शेप), फिर कुछ इंटीग्रेशन टेस्ट से उसे लॉक करें।
एक और जाल ओवर-यूज़ करनाMocks का है।Mocks जो Postgres, ऑथ मिडलवेयर, या असली नेटवर्क के जैसा व्यवहार नहीं करते वे झूठी सुरक्षा देते हैं। प्योर लॉजिक के लिए यूनिट टेस्ट रखें, पर उस चीज़ के लिए थिन इंटीग्रेशन टेस्ट पसंद करें जो प्रॉसेस बॉउंडरी क्रॉस करती है।
तीसरा गलती यह है कि सब कुछ के लिए end-to-end पर निर्भर होना। E2E धीमे और नाज़ुक होते हैं, इसलिए यह केवल उच्चतम मूल्य वाली यूज़र यात्राओं को बचाना चाहिए। ज़्यादातर कवरेज यूनिट और इंटीग्रेशन टेस्ट में रखें जहाँ फेल्यर को डाइग्नोज़ करना आसान हो।
अंत में, फ्लेकिनेस को अनदेखा न करें। अगर टेस्ट कभी-कभी फेल होते हैं, तो टीम सुनना बंद कर देती है। फ्लेकी टेस्ट्स को अपने डिलिवरी पाइपलाइन की बग मानें और जल्दी ठीक करें।
एक त्वरित चेकलिस्ट इससे पहले कि आप और टेस्ट जोड़ें:
अगला कदम: प्लान लागू करें, लेयर द्वारा रिग्रेशन्स को ट्रैक करें, और जानबूझकर सूट छोटा रखें। अगर आप Koder.ai पर बनाते हैं, तो जेनेरेट किए गए API कॉन्ट्रैक्ट की पुष्टि के तुरंत बाद टेस्ट जोड़ना सहायक होता है—और फीचर्स बढ़ाने से पहले ऐसा करें।
अगर आप Koder.ai के ज़रिये जेनरेट किए गए ऐप्स पर काम कर रहे हैं और वेब, बैकएंड और मोबाइल को एक ही जगह पर इटरेट करना चाहते हैं, तो Koder.ai प्लेटफ़ॉर्म उसी वर्कफ़्लो के चारों ओर डिज़ाइन किया गया है। जो भी टूल आप उपयोग करें, टेस्टिंग दृष्टिकोण वही रहता है: कॉन्ट्रैक्ट लॉक करें, मुख्य पाथ कवर करें, और सूट इतना उबाऊ रखें कि आप वास्तव में उसे चलाएँ।
वे अक्सर बाउंड्रीज़ पर फेल होते हैं: UI ↔ API ↔ डेटाबेस. जेनरेट किए गए हिस्से अकेले सही दिख सकते हैं, लेकिन छोटे कॉन्ट्रैक्ट मिसमैच (फ़ील्ड नाम, टाइप, डिफ़ॉल्ट, स्टेटस कोड) तब सामने आते हैं जब असली यूज़र “अल्लड़” करते हैं—दोहरा क्लिक, अजीब इनपुट भेजना, या थोड़ा पुराना क्लाइंट इस्तेमाल करना।
सबसे पहले glue को टेस्ट करें: मुख्य यूज़र फ्लो और उनके नीचे जो API कॉन्ट्रैक्ट होते हैं। आम तौर पर “create/update + validate + save + read back” को कवर करने वाला छोटा सेट कई वास्तविक बग पकड़ लेता है बनिस्बत बहुत सारी UI स्नैपशॉट्स के।
उन रिस्क्स से शुरू करें जो जल्दी महंगे पड़ते हैं:
फिर सबसे छोटे टेस्ट लिखें जो यह साबित करें कि ये चीजें चुपचाप नहीं बदल सकतीं।
पहले श्रेणी तय करें, फिर टेस्ट लिखें।
शुरुआत pure logic टेस्ट से करें (फॉर्मेटर्स, वेलिडेटर्स, APIレス्पॉन्स → व्यू मॉडल मैपिंग, रिड्यूसर/स्टेट मशीन)। फिर कुछ कंपोनेंट टेस्ट जो उपयोगकर्ता की तरह काम करें:
नेटवर्क वाले हिस्सों पर boundary पर मॉक करें और आउटगोइंग पेलोड की कुंजीज़ असर्ट करें ताकि कॉन्ट्रैक्ट ड्रिफ्ट जल्दी मिले।
चार चीज़ें पिन करें:
टेबल-ड्रिवन टेस्ट रखें ताकि एज केस जोड़ना आसान रहे।
fromJson और स्टेट ट्रांज़िशन्स पर ध्यान दें:
fromJson मिसिंग/nullable फील्ड्स को हैंडल करे बिना क्रैश किएसाथ में एक टेस्ट जोड़ें जो यह सुनिश्चित करे कि सर्वर से वेलिडेशन एरर आने पर यूज़र को दोस्ताना संदेश दिखे।
क्रॉस-लेयर ब्रेक्स पकड़ने के लिए:
प्रत्येक टेस्ट एक सीनारियो तक सीमित रखें और सीमित सीड डेटा का प्रयोग करें ताकि वे स्थिर रहें।
उन्हें उबाऊ और कम रखें:
निश्चित बनायें: फिक्स्ड टेस्ट अकाउंट्स, सीडेड डेटा, स्पष्ट वेट्स (रैंडम sleeps ना), और रन के बीच क्लीन स्टेट।
शोर वाले या एक ही गारंटी की नकल करने वाले टेस्ट स्थगित कर दें:
जब कोई वास्तविक बग मिले तभी नया टेस्ट जोड़ें—इस तरह सूट दर्द से बढ़ता है।