आप UI automation का codebase ऐसे कैसे बनाते हैं कि वह संभाले न संभले, ऐसा न हो जाए?

परतें अलग रखिए। page या component objects selectors और निचले स्तर की क्रियाएं समेटते हैं; एक flow परत उन्हें कारोबारी क्रियाओं में जोड़ती है जैसे log in या checkout पूरा करना; टेस्ट में सिर्फ मंशा और assertions रहते हैं। selectors एक ही जगह रखिए, नाजुक CSS paths की जगह अलग से बने test identifiers पसंद कीजिए, और assertions को page objects से बाहर रखिए ताकि फेल होने पर उंगली सही परत की तरफ उठे।

मैं टेस्ट code को production code की तरह मानता हूं, तो वही नियम लागू होते हैं: कोई दोहराव नहीं, साफ परतें, अर्थपूर्ण नाम। सबसे नीचे page या component objects होते हैं जो selectors और UI के उस हिस्से से बरतने की मशीनरी के मालिक हैं। उसके ऊपर कारोबारी स्तर की क्रियाओं के लिए एक flow परत बैठती है, यानी इस role वाले user के तौर पर log in करो, या एक item जोड़कर checkout पूरा करो, क्योंकि ये क्रम लगातार दोबारा इस्तेमाल होते हैं और आप नहीं चाहते कि वे चालीस टेस्ट में copy paste हों। तब टेस्ट खुद requirement की तरह पढ़े जाते हैं, ज्यादातर method calls और assertions। मैं assertions को page objects से बाहर रखता हूं, क्योंकि जब कोई page object assert करता है तो फेल होने पर पता चलता है कि कोई page नाखुश है, यह नहीं कि कौन सा behavior टूटा। selectors पर मैं developers के साथ तय किए गए अलग test attributes के लिए जोर लगाता हूं, क्योंकि हर बार किसी के component को दोबारा style करने पर बदल जाने वाले CSS paths के पीछे भागना ही इन suites के छोड़ दिए जाने की मुख्य वजह है। और setup मैं जहां हो सके API से करता हूं: अगर टेस्ट checkout के बारे में है, तो account और cart HTTP पर बना लेना बारह screens चलाकर वहां पहुंचने से तेज और कहीं कम flaky है।