हरे यूनिट टेस्ट का मतलब यह नहीं कि आप लाइव हो सकते हैं

हम ऑथेंटिकेशन बेचते हैं, और इसी वजह से हमारा सबसे डरावना सवाल बेहद सीधा है: जब कोई ग्राहक अपने ऐप को हमसे जोड़ता है और सब कुछ चालू कर देता है, तो क्या यह असल में, सिरे से सिरे तक, असली चीज़ पर काम करता है? सवाल यह नहीं कि "क्या यूनिट टेस्ट पास होते हैं," बल्कि यह कि क्या एक बिल्कुल नया टेनेंट साइन अप करता है, SSO और SCIM और MFA और कस्टम क्लेम्स और ब्रांडिंग कॉन्फ़िगर करता है, उस पर एक असली एप्लिकेशन को इंगित करता है, और एक असली ब्राउज़र के ज़रिए, टोकन में सही क्लेम्स के साथ एक असली यूज़र को लॉग इन करवाता है। हम इसका जवाब उसी तरीके से देते हैं जिस पर हमें भरोसा है: एक ऐसे एंड-टू-एंड टेस्ट से जो खुद एक ग्राहक बन जाता है।

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

यह हर चीज़ कॉन्फ़िगर करता है, सिर्फ़ हैप्पी-पाथ का एक टुकड़ा नहीं

टेस्ट का बीच का हिस्सा जान-बूझकर बारीक है। यह लॉग इन करके बात ख़त्म नहीं करता; यह हर उस स्क्रीन पर चलता है जिसे एक असली इम्प्लीमेंटर छूता है और उसे असल में आज़माता है: अपने रीडायरेक्ट URI और टोकन सेटिंग्स के साथ एक कस्टम OIDC क्लाइंट, एक कस्टम स्कोप जो यूज़र क्लेम्स देता है, रोल्स और एक रोल असाइनमेंट, एक कस्टम एट्रिब्यूट वाला एंड यूज़र, असली मेंबरशिप वाला एक ग्रुप और एक ग्रुप-टू-रोल मैपिंग, SAML और OIDC एंटरप्राइज़ कनेक्शन, एक SCIM प्रोविज़निंग टोकन, एक कस्टम डोमेन, एक आउटबाउंड प्रोविज़निंग ऐप, एक साथी जिसे आमंत्रित और फिर री-रोल किया गया, एक असली चेकआउट के ज़रिए बिलिंग, फ़िल्टर और CSV एक्सपोर्ट के साथ ऑडिट लॉग, एक सैंडबॉक्स एनवायरनमेंट, और सिक्योरिटी, वेबहुक तथा ईमेल सेटिंग्स (हर एक को बदला गया, फिर एक सुरक्षित स्थिति में वापस लाया गया)। इनमें से हर एक को उसी रन में बनाया, सत्यापित किया और जहाँ उचित हो वहाँ डिलीट किया जाता है।

मक़सद बॉक्स पर टिक लगाना नहीं है। एक ग्राहक कभी किसी एक फ़ीचर को अलग-थलग इस्तेमाल नहीं करता; वह एक संयोजन इस्तेमाल करता है, और संयोजन ही वह जगह हैं जहाँ चीज़ें चुपचाप टूटती हैं। एक कस्टम क्लेम तभी मायने रखता है जब वह जारी किए गए टोकन में दिखे। एक ग्रुप-टू-रोल मैपिंग तभी मायने रखती है जब रोल ठीक उसी पल आए जब टोकन गढ़ा जा रहा हो। जानने का अकेला तरीका यह है कि पूरी चीज़ बनाई जाए और फिर जाकर उसे इस्तेमाल किया जाए।

क्रेडेंशियल का नृत्य

यहाँ वह हिस्सा है जो किसी ऑथ प्रोडक्ट के एंड-टू-एंड टेस्ट को सचमुच पेचीदा बनाता है: जब टेस्ट शुरू होता है तब क्रेडेंशियल मौजूद ही नहीं होते। आप किसी क्लाइंट सीक्रेट या SCIM टोकन को हार्डकोड नहीं कर सकते, क्योंकि पूरी बात ही यह है कि टेनेंट उन्हें रन के दौरान, ताज़ा, गढ़ता है।

तो टेस्ट ठीक वही करता है जो एक असली इम्प्लीमेंटर करता है, बस ज़्यादा तेज़ी से। यह पोर्टल में OIDC क्लाइंट बनाता है और क्लाइंट id तथा सीक्रेट वापस पढ़ता है। यह एक क्लिक में एक Portal API क्रेडेंशियल गढ़ता है और उसे पकड़ लेता है। यह एक SCIM टोकन जनरेट करता है। फिर यह उन ताज़ा-गढ़े गए हर सीक्रेट को तैयार खड़े सैंपल कंज़्यूमर एप्लिकेशन में डालता है, उस ऐप के कॉन्फ़िगरेशन को नई वैल्यू से दोबारा लिखता है, उसे रोल आउट करता है, और तभी असली लॉगिन को चलाता है। एक चरण में जन्मे क्रेडेंशियल अगले चरण में टेस्ट किए जा रहे ऐप में इंजेक्ट किए जाते हैं, और ब्राउज़र उनके विरुद्ध एक असली OIDC रीडायरेक्ट पूरा करता है। इंटीग्रेशन एक चलता-फिरता लक्ष्य है जिसे टेस्ट, ज्यों-ज्यों यह आकार लेता है, खुद पर दोबारा साधता रहता है।

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

मल्टी-फ़ैक्टर, असल में

एक पासवर्ड लॉगिन अपने आप में बहुत कम साबित करता है। रन एक TOTP ऑथेंटिकेटर और एक वर्चुअल ऑथेंटिकेटर के ज़रिए एक WebAuthn क्रेडेंशियल को एनरोल करता है और फिर इस्तेमाल करता है, ताकि दूसरा फ़ैक्टर उसी तरह आज़माया जाए जैसे किसी असली यूज़र का होता है, स्टब करके नहीं छोड़ा जाता।

वह आधा हिस्सा जिसे हर कोई छोड़ देता है: इसे वापस पाना

ज़्यादातर एंड-टू-एंड टेस्ट "यह काम करता है" पर रुक जाते हैं। हमारा उन हिस्सों में आगे बढ़ता रहता है जिनके बारे में आप सिर्फ़ रात के 2 बजे सोचते हैं। यह एक बैकअप लेता है, टेनेंट का डेटा अपने ही नीचे से डिलीट कर देता है, उस बैकअप से रिस्टोर करता है, और सत्यापित करता है कि कॉन्फ़िगरेशन और यूज़र सही-सलामत वापस आ गए। फिर यह पूरे टेनेंट का एक स्वच्छ सेल्फ़-सर्विस डिलीट चलाता है। एक रन पीछे कुछ नहीं छोड़ता, और इसी से हम यह भी जानते हैं कि डीप्रोविज़निंग सचमुच डीप्रोविज़न करती है।

यही वह टेस्ट क्यों है जिस पर हमें भरोसा है

हरे यूनिट टेस्ट की एक दीवार आपको बताती है कि आपके फ़ंक्शन सही हैं। यह आपको बताता है कि एक ग्राहक अंदर आ सकता है, वही इंटीग्रेशन बना सकता है जो वह असल में चाहता है, उन्हीं सिक्योरिटी फ़ीचर्स के साथ जिनकी उसे असल में ज़रूरत है, और यह कि हम उसका डेटा खो सकते हैं और उसे वापस सौंप सकते हैं। यही "कोड सही है" और "हम लाइव हो सकते हैं" के बीच का फ़र्क़ है।

यह रन जिस हर फ़ीचर को आज़माता है (SSO और SAML, SCIM, MFA, कस्टम क्लेम्स और स्कोप, ब्रांडिंग, लागू किए गए वेबहुक, ऑडिट एक्सपोर्ट) वह हर टियर पर प्रोडक्ट में है, किसी एंटरप्राइज़ अपसेल के पीछे बंद नहीं। देखें क्या-क्या शामिल है।