मेरा CI/CD पाइपलाइन 3 महीनों तक पास होता रहा — फिर मैंने लॉग्स पढ़े
हरे रंग के चेकमार्क अच्छे लगते हैं। हर pull request पास हो रहा था। हर deploy काम कर रहा था।
फिर एक यूजर ने एक खराब फीचर की रिपोर्ट की। वह हफ्तों से खराब था।
मैंने पाइपलाइन लॉग्स खोले। हमारी पास होने वाली builds हमसे झूठ बोल रही थीं।
हमारी प्रक्रिया एकदम सही लग रही थी:
- Linting
- Unit tests
- Integration tests
- Build
- Deploy
महीनों तक हर स्टेप का 100% सक्सेस रेट था।
क्लिक करने पर एक्सपोर्ट बटन ने कुछ नहीं किया। कोई error नहीं आया। मैंने इसे 11 हफ्ते पहले किए गए एक बदलाव से जोड़ा। पाइपलाइन पास हो गई थी। कोड रिव्यू को मंजूरी मिल गई थी। फीचर शुरू से ही खराब था।
समस्या हमारा कोड नहीं थी। समस्या हमारा टेस्ट कोड था।
हमारे integration tests हर चीज़ के लिए mocks का उपयोग कर रहे थे। हमने पूरी export service को mock कर दिया था। टेस्ट ने असली कोड के बजाय mock को चेक किया। mock हमेशा success status लौटा रहा था।
हम over-mocking के जाल में फंस गए थे:
- Unit tests: यूनिट को अलग करने के लिए सब कुछ mock किया गया। यह ठीक है।
- Integration tests: स्पीड के लिए सब कुछ mock किया गया। यह एक गलती है।
- E2E tests: इस विशिष्ट flow को मिस कर दिया।
हमारे integration tests सिर्फ महंगे unit tests थे। उन्होंने यह सत्यापित (verify) किया कि हमारे mocks काम कर रहे थे। उन्होंने यह सत्यापित नहीं किया कि हमारा कोड काम कर रहा था।
इसे ठीक करने के लिए मैंने तीन बदलाव किए:
mocks को केवल unit tests तक सीमित रखें। Integration tests को असली databases, APIs और file systems से जुड़ना चाहिए। यदि कोई टेस्ट धीमा है, तो उसे mock के पीछे न छिपाएं। उस धीमी गति का उपयोग optimize करने के संकेत के रूप में करें।
contract tests जोड़ें। ये सुनिश्चित करते हैं कि आपके mocks असली सर्विस के व्यवहार (behavior) से मेल खाते हैं। यदि कोई mock ऐसा डेटा लौटाता है जो असली सर्विस नहीं लौटाएगी, तो contract test फेल हो जाएगा।
वास्तविक coverage को ट्रैक करें। हमने केवल simple pass rates देखना बंद कर दिया। हमने देखा कि टेस्ट वास्तव में क्या चेक कर रहे थे। हमारे coverage नंबर 94% से गिरकर 67% हो गए। यह हमारे पास सबसे ईमानदार metric था।
एक ग्रीन पाइपलाइन का मतलब यह नहीं है कि आपका कोड काम कर रहा है। इसका मतलब है कि आपके टेस्ट पास हो गए हैं। ये दोनों अलग चीजें हैं।
सबसे खतरनाक bugs वे होते हैं जिनके बारे में आपकी पाइपलाइन कहती है कि वे ठीक हैं।
खुद से ये सवाल पूछें:
- क्या मेरे टेस्ट bugs पकड़ रहे हैं या सिर्फ mocks की पुष्टि कर रहे हैं?
- क्या मेरे integration tests वास्तव में integrate करते हैं?
- यदि मैं सभी mocks हटा दूँ, तो कितने टेस्ट अभी भी पास होंगे?
- क्या मैं coverage माप रहा हूँ या confidence?
एक पाइपलाइन जो कभी फेल नहीं होती, वह विश्वसनीय नहीं है। वह untested है।
Source: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj
