आपका end to end suite चार घंटे लेता है और developers ने उसका इंतजार करना छोड़ दिया है। आप इसे कैसे ठीक करेंगे?

चार मोर्चों पर हमला कीजिए: workers पर समानांतर चलाइए, coverage को पिरामिड में नीचे लाइए ताकि API और unit टेस्ट धीमी UI यात्राओं की जगह लें, दोहराव वाले और कम कीमत के टेस्ट काटिए, और setup को UI की जगह API से हालत बनाकर तेज कीजिए। फिर suite को बांटिए ताकि एक तेज हिस्सा merge का दरवाजा रोके और पूरी run रात में चले।

पहले मैं आंकड़े लेता हूं, क्योंकि कौन से टेस्ट धीमे हैं इसका अंदाजा आम तौर पर गलत निकलता है। मैं हर टेस्ट की अवधि निकालता हूं और लगभग हमेशा पाता हूं कि थोड़े से टेस्ट हिस्से से कहीं ज्यादा वक्त खा रहे हैं, अक्सर तय sleep की वजह से या लंबे setup के लिए UI चलाने की वजह से। समानांतर चलाना सबसे तेज ढांचागत जीत है, पर वह तभी काम करता है जब टेस्ट ठीक से अलग थलग हों, तो उसका मतलब आम तौर पर पहले साझा test data ठीक करना होता है। बड़ा लीवर है दोबारा संतुलन। मैं हर end to end टेस्ट को देखकर पूछता हूं कि यह सच में क्या साबित कर रहा है। जो टेस्ट कोई validation message जांचने के लिए छह screens से गुजरता है वह भेस बदले हुए unit टेस्ट है, और उसकी जगह वह परत है जहां वह milliseconds में चलेगा। फिर मैं मिटाता हूं, जो लोगों को असहज लगता है। वे टेस्ट जो किसी असली वजह से कभी फेल नहीं हुए, वे जो कहीं और मौजूद coverage दोहरा रहे हैं, वे जो ऐसे features के हैं जिन्हें कोई इस्तेमाल नहीं करता। जो coverage अपनी कीमत से ज्यादा खर्च कराती है वह बोझ है। और मैं setup API से करता हूं, तो checkout वाला टेस्ट पंद्रह page loads की जगह दो calls में अपना account और cart बना लेता है। आखिर में मैं इसे बांटता हूं: हर merge पर पंद्रह मिनट का अहम रास्ता, पूरा suite रात में।