LogoRRR अपने JavaFX यूज़र इंटरफेस पर इंटीग्रेशन टेस्ट चलाने के लिए TestFX का उपयोग करता है। ये टेस्ट यह सुनिश्चित करते हैं कि मुख्य उपयोग-पथ नए फ़ीचर, रिफ़ैक्टरिंग और डिपेंडेंसी अपडेट के बाद भी काम करते रहें — और वे उन रिग्रेशन को पकड़ते हैं जो यूनिट टेस्ट नहीं देख सकते।
अभी क्यों
20 से अधिक रिलीज़ के बाद, LogoRRR इतना जटिल हो गया था कि केवल मैन्युअल परीक्षण पर्याप्त नहीं रह गया था। कोडबेस को एक सेफ्टी नेट की ज़रूरत थी। TestFX JUnit टेस्ट मेथड से वास्तविक एप्लीकेशन विंडो को चलाना संभव बनाता है — बटन क्लिक करना, फ़ाइलें खोलना, UI स्थिति की जाँच करना।
कब end-to-end टेस्ट में निवेश करना है, यह हमेशा एक समझौता होता है। किसी प्रोजेक्ट की शुरुआत में, UI इतनी तेज़ी से बदलता है कि टेस्ट उसके साथ नहीं चल सकते। लेकिन जब कोर फ्लो स्थिर हो जाते हैं, तो टेस्ट बोझ की बजाय गतिवर्धक बन जाते हैं। वह निर्णायक क्षण 24.3.0 के साथ आया।
कार्यान्वयन
Scala की संक्षिप्त सिंटैक्स एक छोटा टेस्ट DSL बनाने के लिए स्वाभाविक रूप से उपयुक्त है। हर परमाणु क्रिया — एक फ़ाइल खोलना, क्लोज़ बटन क्लिक करना, यह जाँचना कि टैब पेन खाली है — एक पठनीय बिल्डिंग ब्लॉक बन जाती है:
@Test def openAndCloseTab(): Unit = {
checkForEmptyTabPane()
openFile(path)
checkForNonEmptyTabPane()
clickOn(lookup(UiNodes.LogFileHeaderTabs).query[StackPane](), MouseButton.SECONDARY)
waitAndClickVisibleItem(CloseTabMenuItem.uiNode(fileId))
checkForEmptyTabPane()
}
फ्रंटएंड टेस्ट लिखने ने प्रोडक्शन कोड में भी सुधार के लिए मजबूर किया। फ़ाइल I/O और बाहरी प्रोसेस कॉल को एब्स्ट्रैक्ट करने के लिए एक नई Service परत जोड़ी गई — ऐसे बदलाव जो किसी भी टेस्ट लाभ से स्वतंत्र रूप से आर्किटेक्चर में सुधार करते हैं।
टेस्ट ने क्या पकड़ा
- एप्लीकेशन शटडाउन व्यवहार — वे संसाधन जो कभी ठीक से साफ़ नहीं किए गए थे, टेस्ट के तहत स्पष्ट हो गए
- टेस्ट आइसोलेशन — हर टेस्ट को अपनी स्थिति सेट अप और टियर डाउन करनी होती है, जिसने साझा UI स्थिति के बारे में कई सूक्ष्म धारणाएं उजागर कीं
- परफ़ॉर्मेंस बेसलाइन — टेस्ट निष्पादन समय पर नज़र रखने से सुस्त टेस्ट का धीरे-धीरे संचय रोका जाता है
हेडर फ़ोटो Sora Shimazaki द्वारा Pexels पर।