इकाई परीक्षण फाइलें

Question

यूनिट परीक्षण बिल्ड फ़ाइलों के लिए सर्वोत्तम नीतियां क्या हैं?

कारण मैं पूछता हूं कि मेरी कंपनी अत्यधिक विश्वसनीय एम्बेडेड डिवाइस बनाती है। सॉफ़्टवेयर पैच सिर्फ एक विकल्प नहीं हैं, क्योंकि वे हमारे ग्राहकों को वितरित करने के लिए हजारों खर्च करते हैं। इस वजह से हमारे पास बहुत सख्त कोड गुणवत्ता प्रक्रियाएं हैं (इकाई परीक्षण, कोड समीक्षा, tracability, आदि)। उन प्रक्रियाओं को हमारी बिल्ड फाइलों पर लागू किया जा रहा है (अगर आपको पता होना चाहिए तो ऑटोटूल, मुझे करुणा की उम्मीद है), लेकिन अगर हैक की तरह लगता है।

उह ... प्रोजेक्ट संकलित ... बिल्ड फ़ाइलों को समीक्षा और इकाई परीक्षण के रूप में चिह्नित करें।

एक बेहतर तरीका होना चाहिए। विचार?

Answer 1

यहां एक दृष्टिकोण है जो हमने एक दर्जन से अधिक प्लेटफार्मों में एक बड़ा कोड बेस (कोड की कई लाखों लाइनों) का निर्माण करते समय लिया है।

• मेकफ़ाइल परिवर्तनों की समीक्षा टीम द्वारा की जाती है। इन लोगों को हमारे निर्माण वातावरण में लोगों द्वारा की जाने वाली त्रुटियों को पता है, और वे लोग हैं जो बिल्ड ब्रेक होने पर इसका शिकार महसूस करते हैं, इसलिए वे मुद्दों को ढूंढने के लिए प्रेरित होते हैं।
• मेकफ़ाइल में जाने की आवश्यकता को कम करें, इसलिए त्रुटि के लिए कम अवसर हैं। हमारे पास बनाने के शीर्ष पर एक परत है, जो मेकफ़ाइल उत्पन्न करती है। एक डेवलपर को टैग का उपयोग करके उच्च-स्तरीय फ़ाइल में इंगित करना होता है, उदाहरण के लिए एक दिया गया लक्ष्य एक साझा लाइब्रेरी या यूनिट परीक्षण है। आम तौर पर एक लक्ष्य को एक पंक्ति पर परिभाषित किया जाता है, जिसके बाद जेनरेट मेकफ़ाइल में कई सेटिंग्स/लक्ष्य होते हैं। इसी तरह की चीजें बिल्ड टूल्स जैसे scons के साथ की जा सकती हैं जो प्लेटफॉर्म-विशिष्ट विवरण जैसी चीजों को दूर करने की अनुमति देती है, जिससे लक्ष्य बहुत सरल हो जाते हैं।
• हमारे निर्माण उपकरण के यूनिट परीक्षण। टूल पर्ल में लिखा गया है, इसलिए हम पर्ल के Test::More यूनिट टेस्ट फ्रेमवर्क का उपयोग यह सत्यापित करने के लिए करते हैं कि यह टूल हमारी उच्च-स्तरीय फ़ाइल को सही मेकफ़ाइल उत्पन्न करता है। अगर हम इसके बजाय स्कोन की तरह कुछ इस्तेमाल करते हैं, तो मैं their testing framework का उपयोग करता हूं।
• हमारे रात के निर्माण/परीक्षण स्क्रिप्ट के यूनिट परीक्षण। हमारे पास स्क्रिप्ट का एक सेट है जो प्रत्येक प्लेटफ़ॉर्म पर रात का निर्माण शुरू करता है, स्थैतिक विश्लेषण उपकरण चलाता है, यूनिट परीक्षण चलाता है, कार्यात्मक परीक्षण चलाता है, और सभी परिणामों को केंद्रीय डेटाबेस में रिपोर्ट करता है। हम व्यक्तिगत रूप से विभिन्न स्क्रिप्ट का परीक्षण करते हैं, ज्यादातर shunit2 यूनिट-परीक्षण फ्रेमवर्क sh/bash/ksh/etc के लिए उपयोग करते हैं।
• हमारे निर्माण/परीक्षण प्रक्रिया के अंत-से-अंत परीक्षण। मैं एक एंड-टू-एंड टेस्ट पर काम कर रहा हूं जो हमारे उत्पादन कोड की बजाय एक छोटे स्रोत पेड़ पर काम करता है, क्योंकि बाद में निर्माण करने में घंटों लग सकते हैं। ये परीक्षण मुख्य रूप से यह सत्यापित करने के उद्देश्य से हैं कि हमारे निर्माण लक्ष्य अभी भी काम करते हैं और हमारे केंद्रीय डेटाबेस में परिणामों की रिपोर्ट करते हैं, उदाहरण के लिए, हमारे कोड कवरेज टूल को अपग्रेड करना या हमारी बिल्ड स्क्रिप्ट में बदलाव करना।

Answer 2

मेरी परियोजनाओं में बिल्ड-फाइलें अक्सर नहीं बदलती हैं। इससे भी ज्यादा, मैं पहले की परियोजनाओं से बिल्ड-फाइल्स का पुन: उपयोग कर सकता हूं, केवल कुछ चर बदल रहा हूं (जिसे मैं पहचानने में आसान स्थान पर ले गया हूं)। यही कारण है कि मेरे लिए यह बिल्ड-फाइलों का यूनिट-टेस्ट करने के लिए अनियंत्रित है। यह अन्य परियोजनाओं में अलग हो सकता है।

Answer 3

अपनी बिल्ड फ़ाइल को अपने सॉफ़्टवेयर के ज्ञात संस्करण (या कोड के सरल टुकड़े जो कि निर्माण परिप्रेक्ष्य से समान है) संकलित करने के लिए करें और अपने नए बिल्ड टूल्स के साथ अपेक्षित परिणाम की तुलना में अपेक्षित परिणाम की तुलना करें (एक मान्य संस्करण के साथ बनाया गया है) निर्माण उपकरण के)।