KENSAI प्रोडक्ट अपडेट: रात्रिकालीन टेस्ट साक्ष्य ने आरामदेह मेट्रिक की जगह ली

26 अप्रैल की शुरुआत ठीक उसी क़िस्म की विफलता से हुई, जिसे उपयोगी तंत्रों को चिकना करने के बजाय सहेजना चाहिए: रात्रिकालीन फ़्रीमियम टेस्ट सूट पास नहीं हुआ। जीत यह है कि विफलता अब इतनी सटीक है कि ठीक की जा सके।

रात्रिकालीन रन ने क्या साबित किया

26 अप्रैल की क्रॉन रसीद ने प्लेटफ़ॉर्म रिपॉज़िटरी से पूरा KENSAI फ़्रीमियम सूट दर्ज किया। नतीजा कोई धुँधला रेड बिल्ड नहीं था। वह एक ठोस विफलता-नक़्शा था: pnpm test 636 टेस्ट के बाद कोड 1 के साथ बाहर निकला — 310 विफल, 243 पास और 83 छोड़े गए।

विफलता का प्रमुख वर्ग वे API-आधारित टेस्ट थे, जो इस पते पर किसी सेवा की उम्मीद कर रहे थे — 127.0.0.1:4000 — जबकि API उपलब्ध ही नहीं थी, जिससे कनेक्शन अस्वीकृतियाँ और स्टेटस-ज़ीरो एसर्शन पैदा हुए। यह कोई प्रोडक्ट रहस्य नहीं है। यह प्रीफ़्लाइट की कमी और सेवा-ऑर्केस्ट्रेशन की ख़ामी है।

क्या ग़ायब था

दो और खाइयाँ छिपाने के बजाय दर्ज की गईं। रूट पैकेज ने परिभाषित ही नहीं किया — pnpm test:e2e— इसलिए रनर के पास कोई स्थिर e2e प्रवेश-बिंदु नहीं था। कवरेज कमांड तुरंत विफल हो गया, क्योंकि @vitest/coverage-v8 ग़ायब था। सीधा Playwright फ़ॉलबैक चालू ज़रूर हुआ, पर व्यापक auth और admin विफलताओं तथा एक-मिनट के वैलिडेशन टाइमआउट ने उसे इतना शोरगुल भरा बना दिया कि उसे उपयोगी संकेत मानने के बजाय बंद कर देना ही बेहतर था।

यह प्रोडक्ट अपडेट क्यों है

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

KENSAI के लिए यह इसलिए मायने रखता है कि ग्राहक के सामने किए जाने वाले सुरक्षा-दावे उबाऊ संचालनगत सच पर टिके होते हैं। अगर फ़्रीमियम पथ को API चाहिए, तो रनर को टेस्ट शुरू होने से पहले उसे चालू करना या सत्यापित करना होगा। अगर कवरेज ज़रूरी गेट है, तो प्रोवाइडर इंस्टॉल होना चाहिए। और अगर e2e रिलीज़-कहानी का हिस्सा है, तो उसे किसी अनकही परिपाटी के बजाय असली स्क्रिप्ट चाहिए।

अगला मरम्मत-पथ

मरम्मत का क्रम अब साफ़ है: रूट में एक test:e2e स्क्रिप्ट जोड़ो या बहाल करो, कवरेज प्रोवाइडर इंस्टॉल करो, और फ़्रीमियम रनर से यह कराओ कि API-निर्भर टेस्ट चलने से पहले वह पोर्ट 4000 पर API चालू करे और उसकी health जाँचे। इसके अलावा कुछ भी महज़ नाटक होगा।

KENSAI को यही मानक बनाए रखना चाहिए: असहज माप को सहेजो, टूटी हुई पूर्व-शर्तों का नाम लो, और रेड रन को छोटी सुधार-सूची में बदल दो।

निचोड़

उपयोगी मानक सीधा है: दावे तभी असली बनते हैं, जब पूर्व-शर्त, आर्टिफ़ैक्ट और रूट — तीनों एक पंक्ति में आ जाएँ। आज का काम इसी मानक को दिखाई देता रखता है।