वाकई किन चीज़ों के लिए UI testing ज़रूरी है

  • flow शुरू से आख़िर तक काम करता है। यूज़र अपने इरादे से नतीजे तक पहुँच सकता है। इंटरफ़ेस के नीचे की कोई भी परत इसका जवाब नहीं दे सकती।

  • एक step से दूसरे step तक state। एक स्क्रीन पर सेट की गई चीज़ अगली स्क्रीन पर भी मानी जाती है। असली defects यहीं जमा होते हैं।

  • यूज़र को जो बताया गया है, वह असल में हुई बात से मेल खाता है। सफलता का message दिखे लेकिन record सेव न हो — यह सबसे आम झूठ है जो कोई app बोलता है।

UI test में क्या नहीं होना चाहिए

Validation के नियम

  • ब्राउज़र के ज़रिए ग़लत input के हर combination को आज़माना धीमा और नाज़ुक होता है।

  • एक को UI में जाँचें, बाक़ी सब API पर।

गणनाएँ

  • एक unit test इसका जवाब मिलीसेकंड में देता है, और उसका failure message भी बेहतर होता है।

डेटा सेटअप

  • एक fixture बनाने के लिए पाँच स्क्रीन पर क्लिक करते जाना धीमा है और ऐसी वजहों से टूटता है जिनका आप जो टेस्ट कर रहे हैं उससे कोई लेना-देना नहीं।

suite का आकार तय करना

दो काम के नियम। flows को उनकी अहमियत के हिसाब से नहीं, बल्कि इस आधार पर कवर करें कि वे कितनी चुपचाप फेल होंगी, क्योंकि अहम flows पर सबकी नज़र रहती है और चुपचाप वालों पर नहीं। और जब maintenance की लागत उसी समय को खाने लगे जो आप बचा रहे थे, तब जोड़ना बंद कर दें — यह मोड़ ज़्यादातर टीमों की उम्मीद से पहले आ जाता है।

तीन आदतें

  • CSS paths नहीं, स्थिर anchors। redesign से होने वाला ज़्यादातर टूटना ख़त्म कर देता है।

  • समय का नहीं, state का इंतज़ार करें। ज़्यादातर flakiness ख़त्म कर देता है।

  • वही assert करें जिसकी पुष्टि एक reload करेगा। सफलता वाले message से मिलने वाला झूठा भरोसा ख़त्म कर देता है।

किसी टेस्ट को एक परत नीचे खिसकाना, व्यवहार में

इंटरफ़ेस के नीचे जाँच ले जाने की सलाह से सहमत होना आसान है, लेकिन उस पर अमल करना धुँधला रहता है, इसलिए एक असली उदाहरण पर देखिए कि यह दिखता कैसा है।

आपके पास एक browser test है जो signup form को चौदह अलग-अलग ग़लत inputs से भरता है और हर बार error message जाँचता है। इसमें चार मिनट लगते हैं, form का layout बदलते ही यह टूट जाता है, और ब्राउज़र के बारे में यह लगभग कुछ नहीं बताता।

इसकी जगह एक browser test रखें जो एक ग़लत input सबमिट करे और पुष्टि करे कि यूज़र को error दिखाया जा रहा है, साथ में तेरह API tests जो validation के नियमों को सीधे जाँचें। अब browser test ब्राउज़र का सवाल हल करता है, नियम ज़्यादा तेज़ी और ज़्यादा सटीकता से कवर होते हैं, और validation में बदलाव के लिए render होने वाली किसी चीज़ को छूने की ज़रूरत नहीं रहती।

वह हिस्सा जिसे अनुशासन ठीक नहीं कर सकता

Selectors

  • ऐसा redesign जो functional तौर पर कुछ नहीं बदलता, पूरी suite को लाल कर देता है।

  • असल में maintenance का ज़्यादातर समय यहीं जाता है।

इंतज़ार

  • तय delays धीमे होते हैं और फिर भी flaky रहते हैं। सही तरह इंतज़ार करने के लिए यह जानना ज़रूरी है कि इंतज़ार किस चीज़ का है।

  • ज़्यादातर flakiness की जड़ यहीं निकलती है।

हाथ से लिखा गया coverage

  • आप वही कवर करते हैं जो किसी ने लिखा है, यानी दिलचस्प flows, न कि वे जो टूटते हैं।

तीसरी बात ढाँचागत है। लेखक के समय से बँधा coverage ऐसे product से पीछे छूट जाएगा जिसका कोड बढ़ती हुई मात्रा में किसी agent से आ रहा है। इरादे पर आधारित steps और generated coverage इसी हिस्से को संभालते हैं।

Terminal

npm install -g @testsprite/testsprite-cli
testsprite setup

जो लोकल install नहीं चाहते, उनके लिए dashboard यही सब कवर करता है, और पूरा command surface मौजूद है CLI repositoryमें।

dashboard से repository जोड़ दें और runs उसी deployment से शुरू होंगे जो आप पहले से बनाते हैं, या इसके बजाय अपने workflow में एक step जोड़ लें।

TestSprite हर परत पर क्या कवर करता है

ब्राउज़र में चलने वाले flows, जहाँ सिर्फ़ ब्राउज़र ही जवाब दे सकता है, और उसी project में उसके नीचे की API परत। यही बात एक परत नीचे खिसकाने की सलाह को ख़याली के बजाय व्यावहारिक बनाती है: validation के नियम API cases में चले जाते हैं जो सेकंडों में चलते हैं, और एक browser case जाँचता है कि form उनसे जुड़ा हुआ है।

दोनों आपके product से generate होते हैं और सादी भाषा में निखारे जाते हैं, और browser steps selectors नहीं बल्कि इरादे होते हैं, इसलिए suite ऐसे redesigns को झेल जाती है जो functional तौर पर कुछ नहीं बदलते।

आख़िर में आपके पास एक ऐसी browser suite बचती है जो इतनी छोटी है कि लोग उस पर भरोसा करते हैं, जो मायने रखने वाली journeys को कवर करती है, जबकि नियम और edge cases एक परत नीचे ज़्यादा तेज़ी से कवर हो जाते हैं।

कितने UI tests सही हैं?

उतने जितने उन journeys को कवर कर सकें जिनका टूटना आपके लिए शर्मिंदगी की बात होगी, और चुनाव इस आधार पर करें कि वे कितनी चुपचाप फेल होंगी। बाक़ी सब एक परत नीचे खिसका दें।

क्या हमें हर स्क्रीन टेस्ट करनी चाहिए?

नहीं। स्क्रीन नहीं, flows टेस्ट करें। जिस स्क्रीन से होकर कोई flow नहीं गुज़रता, वह शायद ही किसी browser test को सही ठहराती है।

accessibility का क्या?

मशीनी जाँचों के लिए इसे automate करना सही रहता है, और बाक़ी के लिए इंसानी समीक्षा चाहिए। यह एक अलग मसला है जिसके अपने tools हैं।

क्या cross-browser coverage ज़रूरी है?

यह आपके analytics पर निर्भर करता है। कई टीमें एक ब्राउज़र पर पूरी suite चलाती हैं और बाक़ियों पर smoke suite, और आम तौर पर यही सही सौदा है।

UI tests कब चलने चाहिए?

हर pull request पर। इससे कम बार चलाने का मतलब है कि failure एक बदलाव के बजाय बदलावों के पूरे बैच की तरफ़ इशारा करेगा।

संक्षेप में

UI में flows टेस्ट करें, बाक़ी सब उसके नीचे।

UI testing को end-to-end flows, steps के बीच state, और यह कवर करना चाहिए कि यूज़र को जो बताया गया वह असल में हुई बात से मेल खाता है या नहीं। Validation, गणनाएँ और डेटा सेटअप एक परत नीचे के हैं, जहाँ वे ज़्यादा तेज़ हैं और उनकी वजह पकड़ना आसान है।

मुफ़्त शुरू करें हमसे बात करें