curl से टेस्ट करने पर गलत चीज़ टेस्ट होती है

जो काउंटर अनुरोध बिना ब्राउज़र पहचान के आता है, वह उन बारह जगहों में से दो में लिखता है, जिन्हें गिनी गई विज़िट आम तौर पर छूती है। जवाब 200 आता है। एक सही काउंटर इमेज लौटती है। कहीं भी यह नहीं लिखा होता कि बारह में से दस जगहें छोड़ दी गईं।

फ़िल्टर किसलिए है, और इसकी कीमत क्या है

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

ये दोनों बातें सही हैं। सेवा अगर सादे curl को रोबोट मानती है, तो यह गलत नहीं है; वह असल में रोबोट ही है। समस्या यह है कि curl चलाने वाला व्यक्ति आम तौर पर यह नहीं जाँच रहा होता कि रोबोट की पहचान काम करती है या नहीं। वह यह जाँच रहा होता है कि गिनती काम करती है या नहीं, और उसने चुपचाप रोबोट वाला रास्ता माँग लिया है।

उसे मिलता क्या है: दिन के कुल हिट एक बढ़ जाते हैं, बॉट वाला कॉलम एक बढ़ जाता है, और बस। यूनिक विज़िटर की कोई पंक्ति नहीं, इसलिए विज़िटरों के बारे में कुछ नहीं। ऑनलाइन सूची में कोई एंट्री नहीं। न पेज, न देश, न ब्राउज़र, न ऑपरेटिंग सिस्टम, न डिवाइस, न घंटा। सिस्टम के जिन हिस्सों को कोई असल में जाँचना चाहेगा, ठीक वही हिस्से नहीं चले।

इस गड़बड़ी का कोई लक्षण नहीं होता

इस हिस्से पर रुककर सोचना चाहिए। जो टेस्ट कुछ नहीं मापता, वह आम तौर पर खुद बता देता है: कोई गड़बड़ी, खाली नतीजा, जहाँ संख्या होनी चाहिए वहाँ शून्य। यहाँ जवाब 200 है। जवाब की बॉडी एक असली काउंटर इमेज है, पूरे 3,361 बाइट की। तस्वीर में संख्या भी बढ़ गई, क्योंकि कुल हिट उन दो चीज़ों में से एक है जो वाकई हुईं।

इसलिए टेस्ट अनुरोध सफल दिखता है। उसके आधार पर निकली हर बात — “गिनती की प्रक्रिया काम करती है”, “नया कॉलम लिखा जा रहा है”, “बदलाव से कुछ नहीं टूटा” — एक ऐसे रन से निकाला गया निष्कर्ष है, जिसने उस कोड का ज़्यादातर हिस्सा छोड़ दिया जिसे उसे चलाकर परखना था।

यह इसी पोस्ट को लिखते समय हुआ

इस पोस्ट के पीछे वाले माप का पहला वर्ज़न यह पता माँग रहा था: /c/<number>। यह किसी काउंटर इमेज का पता नहीं है; असली पते में डिज़ाइन और एक एक्सटेंशन होता है: /c/<number>-<design>.png। अनुरोध का जवाब 404 आया।

स्क्रिप्ट ने तीन बार यह छापा: 12 में से 0 जगहों में लिखता है। यह सच है, और पहली नज़र में ठीक से काम करता बॉट फ़िल्टर भी बिल्कुल ऐसा ही दिखता। 404 आउटपुट में मौजूद था, उसी टेबल में, शून्यों से एक पंक्ति ऊपर। एक मिनट तक उस पर किसी की नज़र नहीं गई, क्योंकि दिलचस्प हिस्सा शून्य थे और वे उम्मीद के मुताबिक थे।

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

इसकी जगह क्या करें

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

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

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