फ्रंटएंड codebase में क्या टेस्ट करना है और किससे, यह आप कैसे तय करते हैं?

बर्ताव को उसी स्तर पर टेस्ट करें जिस पर यूज़र उसे महसूस करता है। ऐसे component tests जो component render करके दिखने वाले टेक्स्ट और roles से बात करते हैं, प्रति मेहनत सबसे ज़्यादा bugs पकड़ते हैं; formatting और reducers जैसी logic के लिए सादे unit tests ठीक हैं; signup और checkout जैसी अहम यात्राओं के लिए कुछ गिने चुने end to end tests। ऐसे tests से बचें जो implementation की बारीकियों पर दावा करते हैं, क्योंकि वे हर refactor पर टूटते हैं और असली regressions पकड़ते नहीं।

मेरा नियम यह है कि test तब फेल हो जब बर्ताव टूटे और refactor में बचा रहे। तो मेरे ज़्यादातर tests component render करके उसे वैसे चलाते हैं जैसे यूज़र चलाता, elements को test ids या class names की जगह role और label से ढूंढते हुए, जिसका मतलब है component की एक्सेसिबिलिटी की भी कसरत हो जाती है। date formatter या reducer जैसी शुद्ध logic को सादे unit tests मिलते हैं, क्योंकि वे सस्ते और तेज़ हैं। फिर Playwright में एक छोटा end to end suite उन यात्राओं पर जो टूटने पर पैसे की चोट देती हैं: sign up, log in, checkout। network कॉल को fetch function mock करने की जगह सीमा पर mock server से पकड़ा जाता है, ताकि test मेरे असली request वाले कोड को भी कवर करे। मैं बड़े snapshot tests से बचता हूं, क्योंकि दो सौ लाइन के diff को कोई review नहीं करता और वे आंख मूंदकर स्वीकार हो जाते हैं, और अंदरूनी state पर दावा करने वाली किसी भी चीज़ से भी। दूसरी बात जिस पर मैं अड़ता हूं वह यह कि end to end tests किसी seeded एनवायरनमेंट पर चलें, क्योंकि साझा डेटा की चंचलता ही टीमों को लाल builds नज़रअंदाज़ करना सिखाती है।