टेस्ट पिरामिड क्या है, और आज जिस तरह software बनता है उसके हिसाब से क्या वह अब भी टिकता है?

पिरामिड कहता है कि तेज unit टेस्ट बहुत सारे रखिए, integration टेस्ट उससे कम, और end to end टेस्ट थोड़े से, क्योंकि जैसे जैसे आप ऊपर जाते हैं लागत और flakiness बढ़ती है और feedback की रफ्तार गिरती है। लागत के मॉडल के तौर पर यह अब भी टिकता है। जो बदला है वह यह कि distributed services के साथ बीच की परत ज्यादा मायने रखती है, तो contract और integration टेस्ट अक्सर उस क्लासिक आकार से बड़ा हिस्सा पाने लायक होते हैं।

यह आकार अर्थशास्त्र से आता है। एक unit टेस्ट milliseconds में चलता है, ठीक एक ही वजह से फेल होता है, और लगभग कभी झूठ नहीं बोलता। एक end to end टेस्ट मिनटों में चलता है, एक browser, एक network और छह services पर निर्भर होता है, और लाल होने पर आप बीस मिनट यह पता करने में लगाते हैं कि product टूटा है या environment। तो आपको सस्ते वाले ढेर सारे चाहिए और महंगे वाले बस इतने कि यह साबित हो जाए कि टुकड़े आपस में जुड़े हुए हैं। मैंने क्लासिक आकार को distributed systems पर मुड़ते देखा है। अगर कोई service ज्यादातर orchestration है, तो उसे भारी unit टेस्टिंग करना बस आपके अपने mocks को टेस्ट करना है, इसलिए मैं वजन integration और contract टेस्ट में धकेलता हूं, जिससे आकार हीरे के ज्यादा करीब आ जाता है। टेस्ट कहां रखा जाए यह तय करने का मेरा नियम है यह पूछना कि सबसे छोटी कौन सी चीज है जो इस behavior को तोड़ सकती है, और उसी स्तर पर टेस्ट करना। अगर रिस्क किसी गणना में है, तो unit। अगर रिस्क यह है कि दो services किसी payload पर असहमत हैं, तो contract। end to end मैं मुट्ठी भर उन यात्राओं के लिए रखता हूं जिन्हें कभी चुपचाप नहीं टूटना चाहिए।