आपके app में captcha हो तो CI हरा कैसे रखें
आपके sign-up form पर PopularCaptcha है। आपके end-to-end suite को sign up करना है। अब CI लाल है, और सबसे आसान उपाय, test build में captcha बंद कर देना, मतलब यह है कि जो flow आप test कर रहे हैं वह वह नहीं है जो आपके users को मिलता है।
इससे निकलने के कई रास्ते हैं। वे इस बात में अलग हैं कि वे असली flow को कितना इस्तेमाल करते हैं, इसलिए वह चुनें जो उस सवाल से मेल खाए जिसका जवाब आपका test देता है। ये विकल्प हैं, सबसे सस्ते से लेकर सबसे यथार्थवादी तक।
Scarnox आज PopularCaptcha solve करता है। Captcha के बाकी प्रकार जल्द आ रहे हैं, इसलिए नीचे का solving विकल्प केवल PopularCaptcha के लिए है।
1. Unit और local tests के लिए test keys
कई captcha providers ऐसी test keys देते हैं जो हमेशा पास होती हैं। इन्हें तब इस्तेमाल करें जब environment आपके नियंत्रण में हो और आपको केवल यह देखना हो कि form रेंडर होता है और submit होता है। Test keys असली verification की जाँच नहीं करतीं, और जब आप ऐसे deployed environment की test करते हैं जो असली keys इस्तेमाल करता है, तो वे मदद नहीं करतीं।
2. अपनी staging के लिए bypass
कुछ टीमें backend में एक secret header जोड़ती हैं जिसे captcha token की जगह स्वीकार किया जाता है। यह तेज़ और मुफ़्त है, लेकिन यह ऐसा code path है जो केवल tests के लिए मौजूद है, और एक गलत configuration दूर है production में मौजूद होने से। अगर आप इसका इस्तेमाल करें, तो इसे environment check के पीछे रखें, secret को लंबा और random बनाएँ, और जाँचें कि production में यह reject होता है।
3. Verification call को mock करें
Integration tests में server-side verification request को stub करें। यह आपके backend logic की जाँच के लिए अच्छा है, जैसे verification fail होने पर क्या होता है। पर यह नहीं बताता कि front end token सही भेजता है या नहीं, इसलिए इसे दूसरे विकल्पों में से किसी के साथ जोड़ें।
4. Staging और smoke tests में असली solve करें
जब आपको यह साबित करना हो कि असली flow end to end काम करता है, असली keys, असली widget और असली verification के साथ, तो test के भीतर solving API से token लाएँ। यही एकमात्र विकल्प है जो टूटे हुए widget integration को पकड़ता है।
एक Playwright helper ऐसा दिखता है:
// Playwright test के लिए helper
export async function solveCaptcha(page) {
const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
const r = await fetch("https://api.scarnox.com/api/tasks/create", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
captcha_type: "PopularCaptchaTaskProxyless",
site_key: sitekey,
site_url: page.url(),
}),
});
const { errorId, solution, errorCode, errorDescription } = await r.json();
if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);
await page.evaluate((t) => {
document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
.forEach((el) => { el.value = t; });
}, solution.token);
}इसे test में submit से ठीक पहले बुलाएँ, test की शुरुआत में नहीं। Tokens लगभग दो मिनट में expire होते हैं, और test में पहले का कोई धीमा step उस window को खा सकता है।
Solves को न्यूनतम रखें
जो suite हर run पर sign up करता है, वह एक हफ़्ते में बहुत सारे solves कर सकता है। संख्या कम रखें:
- असली solve केवल staging और smoke test में चलाएँ। दूसरे विकल्प हर commit पर इस्तेमाल करें।
- असली solve हर pipeline में एक बार चलाएँ, हर test file में नहीं।
- अपने helper में प्रति run solves की सीमा तय करें। जो test इसलिए फ़ेल होता है क्योंकि सीमा पहुँच गई, वह suite की समीक्षा का स्पष्ट संकेत है।
- विफल solves मुफ़्त हैं, इसलिए एक flaky step समय बर्बाद करता है, पैसे नहीं। पर जो suite बिना सोचे retry करता है, वह फिर भी runner minutes बर्बाद करता है।
Helper के भीतर retry नियमों के लिए error handling और backoff की policy इस्तेमाल करें।
Key को repo से बाहर रखें
Key को CI secret के रूप में रखें, जिसका नाम कुछ ऐसा हो जैसे SCARNOX_KEY, और उसे कभी test code या fixtures में न डालें। अगर वह लीक हो, तो dashboard से उसे दोबारा बनाएँ। पुरानी key तुरंत काम करना बंद कर देती है, इसलिए लीक हुई key लंबे समय तक solves चलाने के काम नहीं आ सकती।
CI के लिए अलग key इस्तेमाल करें। अगर एक pipeline गड़बड़ करे, तो आप उस key को बदल सकते हैं बिना किसी और चीज़ को छुए।
अपनी staging पर आज़माएँ
खाता बनाएँ और मुफ़्त ट्रायल क्रेडिट से शुरू करें, कार्ड की ज़रूरत नहीं। पहले helper को एक smoke test में जोड़ें, जाँचें कि वह साफ़ तौर पर sign up करता है, और तभी उसे पूरे suite में जोड़ें। Volume पर solving की लागत के लिए मौजूदा pricing देखें।
Submit के बाद क्या assert करें
एक solved captcha केवल यह साबित करता है कि widget वाला step काम कर गया। Submit के बाद उन बातों को assert करें जो user के लिए मायने रखती हैं: अगला page लोड होता है, सफलता का संदेश दिखता है, और account या order आपके database में मौजूद है। ऐसा test जो "form पर कोई error नहीं" पर रुक जाता है, पास हो सकता है जबकि backend पर signup चुपचाप फ़ेल हो गया हो।
Assertions को business परिणाम के करीब रखें। URL, दिखने वाला संदेश और test द्वारा बनाया गया एक record जाँचें। Run के अंत में वह record मिटा दें, ताकि अगला run एक ज्ञात स्थिति से शुरू हो।
Smoke test को schedule पर चलाना
असली-solve वाला smoke test schedule पर चलाएँ, जैसे staging के खिलाफ़ रोज़ एक बार, न कि हर pull request पर। Scheduled runs site में रात भर हुए बदलाव पकड़ते हैं, जैसे नया widget version या बदली हुई sitekey, बिना हर commit पर solves खर्च किए। जब scheduled run फ़ेल हो, तो टीम को सूचित करें, और हर commit वाला suite तेज़ विकल्पों पर रखें।