वे तीन रनटाइम खामियाँ जिन्हें वेब ऐप्स टेस्टिंग को कवर करना ही चाहिए
पीछे छूटी हुई state
कोई modal बंद होता है और scroll lock छोड़ जाता है। कोई filter वहाँ भी बना रहता है जहाँ उसका कोई मतलब नहीं।
यह सिर्फ़ दूसरी बार इस्तेमाल करने पर दिखती है, इसलिए नए सिरे से किया गया reproduction इसे कभी नहीं पकड़ता।
डेटा से पहले render
पेज पेंट हो जाता है, fetch पूरा हो जाता है, और कुछ भी re-render नहीं होता।
आमतौर पर रुक-रुक कर होती है, इसीलिए review में बच निकलती है।
दूसरा user
ownership और visibility को लेकर ऐसी धारणाएँ जो developer के अपने session से बनी हैं।
जिन्होंने इसे बनाया, उन सबके लिए यह बिल्कुल ठीक चलता है।
वह एक जाँच जो इनमें से ज़्यादातर पकड़ लेती है
वही काम दो बार करें, दो अलग users बनकर, और बीच में एक reload कर दें। यह अकेला pattern तीनों श्रेणियों को छू लेता है, और यही वह चीज़ है जिसे manual testing छोड़ देती है, क्योंकि पहली कोशिश तो चल ही गई थी।
assert क्या करें
ऐसी कोई चीज़ जिसकी पुष्टि एक reload कर दे। success message इस बात का सबूत नहीं है कि कुछ सचमुच सेव हुआ। उस चीज़ को वापस fetch करके देखें।
जो नहीं होना चाहिए, उसका न होना। delete करने के बाद वह row ग़ायब है। sign out करने के बाद वह डेटा दिखता नहीं है।
किसी और के लिए व्यवहार। दूसरा account पहले account के records नहीं देख सकता।
इसमें लोकल डेवलपमेंट कहाँ आता है
वेब ऐप का काम किसी भी deploy से बहुत पहले localhost पर होता है, और ऐसी जाँच जो सिर्फ़ किसी public URL पर चलती है, इतनी देर से आती है कि आप जो बना रहे हैं उसमें कुछ बदल नहीं पाती। CLI frontend runs के लिए आपकी अपनी मशीन पर चल रहे ऐप तक tunnel बना सकता है, इसलिए यह जाँच तब भी उपलब्ध रहती है जब आप काम ही कर रहे होते हैं। विवरण के लिए देखें CLI रिपॉज़िटरी।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोग लोकल install नहीं करना चाहते, उनके लिए dashboard भी यही सब कवर कर देता है।
दो-टैब वाला टेस्ट
हर release से पहले एक manual जाँच ऐसी है जो अपनी लागत से ज़्यादा पकड़ती है, और लगभग कोई इसे नहीं करता: ऐप को दो tabs में खोलिए।
पहले tab में कुछ कीजिए, फिर दूसरे को देखिए। ज़्यादातर वेब ऐप्स यहाँ किसी न किसी तरह ग़लत बर्ताव करते हैं, और वह ग़लती अपने आप में जानकारी देती है। कोई list अपडेट न हो, तो आमतौर पर यह ठीक है। कोई पुराना action सफल हो जाए और नए डेटा को overwrite कर दे, तो यह असली bug है। कोई session एक tab को इसलिए logout कर दे क्योंकि दूसरे ने token refresh किया, तो यह असली bug है। कोई optimistic update जो कभी reconcile ही न हो, वह असली bug है।
इसमें दो मिनट लगते हैं, किसी tooling की ज़रूरत नहीं पड़ती, और यह ठीक उसी जोड़ पर दबाव डालता है जहाँ server state, browser state और user की उम्मीद आपस में मेल नहीं खातीं। अगर इस पेज से आप सिर्फ़ एक आदत अपनाएँ, तो यही अपनाइए।
इसे लगातार चलने दें
रनटाइम की खामियाँ ठीक वही हैं जो बार-बार लौट आती हैं, क्योंकि उन्हें पैदा करने वाली परिस्थितियाँ अनजाने में आसानी से दोबारा बन जाती हैं।
GitHub App एक webhook है जिसे आप TestSprite dashboard में सेट करते हैं। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी repository में कुछ भी नहीं बदलता।
GitHub Actions इस step को आपकी अपनी workflow के भीतर रख देता है, जिसे terminal से configure किया जाता है।
TestSprite चल रहे ऐप को कैसे परखता है
यह deploy किए गए ऐप्लिकेशन को खोलता है और उसे वैसे ही इस्तेमाल करता है जैसे कोई इंसान करता, और पीछे छूटी हुई state, डेटा से पहले render तथा दूसरे user के व्यवहार को देखने का यही एक तरीक़ा है। cases सरल भाषा में लिखे जाते हैं और आपके प्रोडक्ट से ही तैयार होते हैं, और ये उन चीज़ों पर assert करते हैं जिनकी पुष्टि एक reload कर दे, न कि client द्वारा दिखाए गए किसी message पर।
दूसरे user वाली जाँच यहाँ सेटअप की कोई औपचारिकता नहीं, बल्कि पूरा एक case है — और यह मायने रखता है, क्योंकि permission को लेकर बनी धारणाएँ वह खामी हैं जिनके ग्राहक तक पहुँचने की संभावना सबसे ज़्यादा है और जिन पर feature बनाने वाले की नज़र पड़ने की संभावना सबसे कम।
इसके बाद ये जाँचें हर बदलाव पर चलती रहती हैं, ताकि तीनों states के बीच का जो टकराव एक बार bug बना चुका है, वह branch merge होने के बाद चुपचाप लौट न आए।
ये code review में क्यों नहीं पकड़े जाते?
क्योंकि ये server state, browser state और इतिहास के आपसी मेल के गुण हैं। diff इनमें से कुछ भी नहीं दिखाता।
क्या हम इसे unit tests से टेस्ट कर सकते हैं?
कुछ हद तक, ढेर सारी mocking के साथ — और उन mocks में वही धारणाएँ बैठी होती हैं जो कोड में हैं। असली चीज़ को चलाकर देखना ही फ़ैसला करता है।
दूसरे user को भरोसेमंद तरीक़े से कैसे टेस्ट करें?
हर environment में एक दूसरा account रखें और वही flow दोनों बनकर चलाएँ। वेब ऐप टेस्टिंग में यह सबसे सस्ती और सबसे ज़्यादा नतीजे देने वाली जाँच है।
मोबाइल ब्राउज़र्स का क्या?
viewport के अंतर से layout और interaction की एक अलग तरह की समस्याएँ सामने आती हैं। अगर आपके पास मोबाइल ट्रैफ़िक है, तो मुख्य flows को मोबाइल साइज़ पर कवर करना सही रहेगा।
इसमें से कितना लोकल चलाया जा सकता है?
frontend runs एक tunnel के ज़रिए आपकी मशीन पर चल रहे ऐप तक पहुँच सकते हैं। जो backend targets पहुँच में नहीं हैं, उनके लिए अब भी बाहर से पहुँच योग्य environment चाहिए।
दो बार कीजिए, दो users बनकर, बीच में एक reload के साथ।
वेब ऐप्स टेस्टिंग को पीछे छूटी हुई state, डेटा से पहले render और दूसरे user के व्यवहार को कवर करना होता है, और इनमें से कुछ भी सोर्स कोड में नहीं दिखता। उसी पर assert करें जिसकी पुष्टि reload करता है, जो हट जाना चाहिए उसका न होना जाँचें, और वही flow किसी और बनकर भी चलाएँ।