वह दौर जब test code नई moat बन जाता है
(saewitz.com)-
सफलता का विरोधाभास: जैसे-जैसे कोई प्रोजेक्ट बढ़ता है, उसे backward compatibility और विशाल codebase (The Ship of Theseus) का बोझ उठाना पड़ता है। दूसरी ओर, प्रतिस्पर्धी मौजूदा प्रोजेक्ट की API spec, documentation और test code को AI से सीखाकर केवल core value निकालते हुए एक 'ज़्यादा हल्का और आधुनिक version' पल भर में बना सकते हैं.
-
Cloudflare vs Vercel मामला: Cloudflare ने Vercel द्वारा वर्षों में तैयार किए गए Next.js के विशाल documentation और test suite का उपयोग करके, सिर्फ़ एक हफ्ते में Vite-आधारित slim Next.js-compatible runtime बना लिया। (फ़िलहाल यह अमेरिकी सरकारी साइट cio.gov पर भी लागू है)
-
test code ही asset है: पहले code खुद सबसे महत्वपूर्ण था, लेकिन अब 'software contract' और 'test case' सबसे महंगे asset बन गए हैं। इन्हें सार्वजनिक करना ऐसा है जैसे प्रतिस्पर्धी को मेरी service की हूबहू नकल करने के लिए एक सटीक blueprint दे देना।
-
SQLite की दूरदर्शिता: SQLite code को public रखता है, लेकिन source code से 590 गुना बड़े विशाल test suite (92 million lines) को private रखता है। यही वह 'moat' है जिसने open source ecosystem को बनाए रखते हुए भी उसे commercial defense दी है।
-
निष्कर्ष: AI युग की commercial open source कंपनियाँ अब 'पूर्ण परोपकार (open source)' और 'business survival' के बीच निर्णय लेने के मोड़ पर खड़ी हैं। आगे कई प्रोजेक्ट SQLite की तरह test code को private में बदलते हुए अपनी अलग technical barrier खड़ी करते दिख सकते हैं.
19 टिप्पणियां
अगर इस नज़रिए से देखें, तो शायद ADR(Architecture Decision Records) या CIR(Change Intent Records) जैसे दस्तावेज़ों को खुद कोड से भी ज़्यादा क़ीमती माना जाने लगे।
काफ़ी प्रभावशाली है। यह छोटा सा लेख होने के बावजूद तुरंत समझ में आ जाता है। हो सकता है कि test code की security source code से भी ज़्यादा महत्वपूर्ण हो।
मुझे तो यह बात e2e tests को कभी न छोड़ने की सलाह जैसी लगती है, लेकिन बाकी लोग इसके बारे में क्या सोचते हैं, यह जानने की उत्सुकता है।
मैं पूरी तरह non-developer हूँ... AI के साथ छेड़छाड़ करने के मज़े में उससे थोड़ी coding करवा रहा था, तो उसने बिना कहे ही ढेर सारे test code बनाकर संभालकर रख दिए; अब समझ आया कि इसकी ऐसी वजह थी।
जब मैंने पूछा कि आखिर इसकी ज़रूरत ही क्यों है, तो उसने कहा कि उसे code बनाते समय इसकी ज़रूरत पड़ती है, इसलिए इन्हें मत हटाइए।
ओ... लगता है यह सही है।
SQLite का अप्रोच वाकई बहुत प्रभावशाली है। कोड के मुकाबले 590 गुना बड़े test suite को private रखना, आखिरकार यही बताता है कि "software की असली value उसके behavior specification में होती है।"
वास्तव में आजकल AI coding tools से project बनाकर देखें, तो अगर किसी मौजूदा project का README + API docs + test code ही मौजूद हो, तो उसकी core functionality को हैरान कर देने वाली तेजी से replicate किया जा सकता है। मैं खुद 7 projects चलाते हुए यह महसूस कर चुका हूँ कि जिन projects में tests अच्छे होते हैं, उन्हें विडंबना यह है कि replicate करना भी उतना ही आसान होता है।
लेकिन Cloudflare vs Vercel उदाहरण में एक बात नजरअंदाज हुई है: "replication" और "operations" पूरी तरह अलग समस्याएँ हैं। Next.js के edge cases, plugin ecosystem, और community dependency तक दोबारा तैयार करनी हो, तो सिर्फ test code काफी नहीं है। आखिर में moat शायद test code + community + operational know-how का संयोजन ही होता है।
मैं एक solo developer के तौर पर 7 projects चला रहा हूँ, और यह लेख सच में बहुत गहराई से लगा।
AI coding tools की वजह से शुरुआती development speed पागलों जैसी तेज़ हो गई है, लेकिन बिना test के जल्दी-जल्दी जो code बनाया, वह आखिरकार refactoring hell बन गया। खासकर जब कई services एक साथ चला रहे हों, तो जिस project में tests नहीं होते, उसमें एक feature को छूने भर से डर लगता है कि कहीं कुछ और न टूट जाए।
"tests = moat" वाली उपमा बिल्कुल सटीक है। competitor code को copy कर सकता है, लेकिन हज़ारों edge cases को cover करने वाली test suite को copy करना आसान नहीं है। खास तौर पर इसलिए भी, क्योंकि AI code generation तो अच्छी तरह कर लेता है, लेकिन meaningful test scenarios बनाना अभी भी ऐसा क्षेत्र है जहाँ इंसानी domain knowledge की ज़रूरत पड़ती है.
लेकिन क्षेत्र के अनुसार ऐसे मामले भी होते हैं जहाँ test code की coverage लगभग न के बराबर होती है, इसलिए यह सोचने वाली बात लगती है। उस तरफ़ अभी भी दूसरे क्षेत्रों की तुलना में अच्छा code बनाने में उतनी पकड़ नहीं दिखती, ऐसा भी लगता है।
क्या आप कृपया बता सकते हैं कि वह क्षेत्र कौन-सा है? (यह बहस के लिए नहीं, सच में सिर्फ़ जिज्ञासा से पूछ रहा/रही हूँ.)
मैं जिस क्षेत्र में काम करता हूँ वह इतना चरम स्तर का तो नहीं है, लेकिन मैं AI क्षेत्र में research और development कर रहा हूँ.
आम तौर पर बहुत इस्तेमाल होने वाले framework के अलावा, कई बार जिस target environment में मॉडल को वास्तव में deploy किया जाता है, वह training वाले environment से अलग होता है.
कभी-कभी कुछ specific operation support नहीं करते, इसलिए platform के हिसाब से custom operation बनाना पड़ता है. ऐसे मामलों में कई बार development environment में ही तुरंत test करना संभव नहीं होता.
कई बार हम सीधे मॉडलिंग भी करते हैं. किसी खास data के साथ test code लिखा जा सकता है, लेकिन dataset के अनुसार values probabilistically बदलती रहती हैं, और किसी खास समय पर values का explode हो जाना जैसी घटनाओं को test code से cover करना मुश्किल होता है.
शायद मुझसे भी ज़्यादा testing कठिन होने वाले environment काफी होंगे.
यह सिर्फ़ मेरा विचार है, लेकिन शायद वे क्षेत्र होंगे जहाँ Notebook का इस्तेमाल ज़्यादा होता है, या AI जैसे क्षेत्र जहाँ जवाब प्रायिकता के आधार पर आते हैं, और गेम client जैसे क्षेत्र भी।
मैं भी अपने आसपास यह बात बहुत करता हूँ, लेकिन आखिरकार बाद में सारे कोड को विस्तार से देख पाना मुश्किल होगा, इसलिए मेरा मानना है कि सच में महत्वपूर्ण logic का बिना शर्त test न किया जाए तो बड़ी मुसीबत हो सकती है।
लेख के नीचे भी यह जोड़ा गया था कि tldraw भी अपने टेस्ट private में चलाता है, ऐसी बात कही गई थी (बाद में पता चला कि वह मज़ाक था).
https://github.com/tldraw/tldraw/issues/8082
SQLite का टेस्ट कैसे किया जाता है देखें।
SQLite पूरी तरह public है, लेकिन source code की तुलना में 590 गुना अधिक test code है, और वह पूरी तरह private है.
100% branch coverage, लाखों test cases, और 1 अरब से अधिक mutation tests चलाए जाते हैं.
इश्यू में जाकर पढ़ा तो लिखा है कि यह "joke" है।
लगता है वह Joke टेस्ट था।
अरे, ऐसा है। मैंने तो सिर्फ ऊपर का हिस्सा देखकर ही हा हा
"source से ज़्यादा test"वाली बात सच में सही लगती है। लेकिन open test किए बिना सिर्फ open source करने की strategy कितनी कारगर होगी, यह पक्का नहीं है। source से test items निकालना भी शायद वे काफ़ी अच्छी तरह कर लेंगे..वे इसे गलत कर देते हैं।
https://hi.news.hada.io/topic?id=26988
लगता है कि यह लेख इससे जुड़ा हुआ है। open source करते समय, test code को सार्वजनिक करने के मामले में अब शायद अधिक सतर्क रुख अपनाना पड़ सकता है।