स्वचालित परीक्षण के साथ retrofitting विरासत कोड के लिए सर्वोत्तम प्रक्रियाएं

22

मैं अपेक्षाकृत बड़े और पुराने कोड बेस में पहले से परिभाषित इंटरफ़ेस (C ++ हैडर फ़ाइलों का एक सेट) को फिर से लागू करने के बारे में हूं। ऐसा करने से पहले, मैं यथासंभव पूर्ण परीक्षण कवरेज करना चाहता हूं, इसलिए मैं पुन: कार्यान्वयन त्रुटियों का जल्द से जल्द और आसानी से पता लगा सकता हूं। समस्या यह है कि पहले से मौजूद कोड बेस को आसानी से परीक्षण योग्य नहीं बनाया गया था, (बहुत) बड़ी कक्षाओं और कार्यों के साथ, युग्मन की एक उच्च डिग्री, (कई) साइड इफेक्ट्स आदि के साथ कार्य करता है।

इसी तरह के कार्यों के साथ किसी भी पिछले अनुभव को सुनना अच्छा होगा, और आपके विरासत कोड के लिए स्वचालित परीक्षण (इकाई, एकीकरण, प्रतिगमन, आदि) के बारे में कुछ अच्छे और ठोस सुझाव दिए गए हैं।

testing legacy

— tjansson
स्रोत

1

चरण 1: खोज ढेर अतिप्रवाह। सवाल पूछा गया है। कई, कई बार।

— S.Lott

20

सबसे पहले, माइकल फेदर्स द्वारा वर्किंग इफेक्टिवली विथ लिगेसी कोड प्राप्त करें और पढ़ें - यह ऐसे कार्यों के लिए एक अनिवार्य सहायता है।

फिर, कुछ नोट्स:

क्या आपके पास इंटरफ़ेस के लिए एक सटीक विनिर्देश / अनुबंध है, या क्या आपके पास व्यावहारिक रूप से केवल "विनिर्देश" के रूप में मौजूदा कार्यान्वयन है? पूर्व मामले में खरोंच से एक पूर्ण पुनर्लेखन करना आसान है, बाद में यह असंभव है।
यदि आप इंटरफ़ेस को फिर से लागू करना चाहते हैं, तो अपने परीक्षण संसाधनों को खर्च करने का सबसे उपयोगी तरीका केवल इंटरफ़ेस के खिलाफ परीक्षण लिखना है। बेशक, यह सख्त अर्थों में इकाई परीक्षण के रूप में योग्य नहीं है, बल्कि कार्यात्मक / स्वीकृति परीक्षण है, लेकिन मैं शुद्ध नहीं हूं :-) हालांकि, ये परीक्षण पुन: प्रयोज्य हैं और आपको दो कार्यान्वयनों के परिणामों की सीधे-सीधे तुलना करने में सक्षम बनाते हैं ।
कुल मिलाकर, मैं खरोंच से पुनर्लेखन के बजाय मौजूदा कोड को वापस लेने का पक्ष लूंगा, जब तक कि यह पूरी तरह से अप्राप्य न हो। (लेकिन इस मामले में, आप वैसे भी इसके खिलाफ इकाई परीक्षण कैसे लिखने जा रहे हैं?) इस विषय पर अधिक विस्तृत चर्चा के लिए जोएल से इस पोस्ट को देखें । इंटरफेस के खिलाफ स्वीकृति परीक्षणों का एक सेट बनाने से आपको एक पतली, लेकिन उपयोगी सुरक्षा जाल प्राप्त होता है, जिसके खिलाफ आप मौजूदा कोड को इकाई परीक्षण योग्य बनाने (पंखों की किताब से विचारों का उपयोग करके) के प्रति सतर्कतापूर्वक शुरुआत कर सकते हैं।

— पेटर टॉर्क
स्रोत

अगर मैं कर सकता तो मैं इसे +3 करता। WELC एक आवश्यक पढ़ा है और निश्चित रूप से एक refactoring के लिए जाना है ...

— Johnsyweb

2 अंक पर एक छोटी सी टिप्पणी यह है कि विरासत प्रणालियों के लिए, परीक्षण चरित्र मानसिकता के अनुसार परीक्षण किया जाना चाहिए । यही है, ईमानदारी से सॉफ्टवेयर के वर्तमान व्यवहार को पकड़ते हैं, और यूनिट परीक्षण मानसिकता के अनुसार कुछ परीक्षा परिणाम अजीब या सहमत नहीं होने पर भी व्यवहार को बदलने से बचते हैं। (Btw इस विचार भी Welc के लेखक से आता है।)

— rwong

@rwong, वास्तव में। एक विस्तृत विनिर्देशन, या एक जानकार उत्पाद स्वामी के बिना, डेवलपर के लिए यह तय करना असंभव है कि क्या कार्यक्रम का एक विशिष्ट व्यवहार ए) जानबूझकर और आवश्यक है, ख) अनजाने में था, लेकिन अब तक उपयोगकर्ता इस पर निर्भर करते हैं, ग) एक बग जो वास्तव में उपयोगकर्ताओं को परेशान करता है, घ) एक बग पूरी तरह से अब तक किसी का ध्यान नहीं है। पहले दो मामलों में, "फिक्सिंग" यह वास्तव में उपयोगकर्ताओं को चोट पहुंचाएगा, और अंतिम मामले में, फिक्स - हालांकि सैद्धांतिक रूप से सही है - कोई दृश्य लाभ प्रदान नहीं करेगा।

— पेटर तोर्क

4

सबसे अच्छी विधि पता है कि मिकादो विधि है। http://mikadomethod.wordpress.com/2010/08/04/the-mikado-method-book/ यह केवल एक साधारण तकनीक का सामान्यीकरण है, लेकिन यह एकमात्र तरीका है जिसे मैं एक बड़े कोड आधार में कोड गुणवत्ता में सुधार करना शुरू करना जानता हूं बिना अनावश्यक जोखिम उठाए।

WEWLC भी इसके बारे में एक बहुत अच्छी किताब है लेकिन C ++ में लिखा जाना हमेशा जावा या रूबी कोड के साथ उपयोगी नहीं होता है।

— Uberto
स्रोत

2

एक पुराने कोड बेस पर रेट्रो फिटिंग परीक्षण काफी मुश्किल हो सकता है अगर यह डिजाइन में अखंड हो।

यदि संभव हो (क्या आपके पास समय / धन है), आगे बढ़ने का एक तरीका कोड को अधिक परीक्षण योग्य इकाइयों में फिर से सक्रिय करना होगा।

— ozz
स्रोत

1

मैं एक लिंक जोड़ना चाहूंगा । अधिक एक्सयूनिट फ्रेंडली कोड में पुनर्मूल्यांकन नहीं करने के लिए बहुत आसान उदाहरण हैं। सामान्य दृष्टिकोण के लिए के रूप में पहले से ही उल्लेख लिंक (जोएल पोस्ट, लिगेसी कोड के साथ काम कर रहे हैं

— yoosiba
स्रोत