गेम के सॉफ्टवेयर को ऐसे कैसे डिज़ाइन करें कि यूनिट टेस्ट करना आसान हो?

25

क्या एक खेल विकास की स्थिति में JUnit जैसे परीक्षण ढांचे का उपयोग करना व्यावहारिक है? अपने गेम को और अधिक परीक्षण योग्य बनाने के लिए आप किस प्रकार के डिज़ाइन विचार का अनुसरण कर सकते हैं? एक खेल के किन हिस्सों का परीक्षण / परीक्षण किया जाना चाहिए और किन भागों को मानव परीक्षण के लिए छोड़ दिया जाना चाहिए / होना चाहिए?

उदाहरण के लिए, यदि गेम लूप को एक फ़ंक्शन में एनकैप्सुलेट किया गया है, तो ऐसा लगता है कि यह परीक्षण करना बहुत कठिन होगा। मैं एक "अपडेट" फ़ंक्शन को रिफ्लेक्टर करना पसंद करता हूं जो एक समय डेल्टा लेता है और खेल तर्क को आगे बढ़ाता है; यह खेल को धीमा करने की क्षमता जैसे कुछ दिलचस्प ट्रिक्स की अनुमति देता है जो इसे नकली, धीमी गति से देरी से खिलाता है।

architecture  unit-testing 
— Ricket
स्रोत
6
जब आप गुलाम श्रम की लगभग अंतहीन सेना है, तो आपके लिए नाटक करने के लिए मानव-घंटे लेखन इकाई परीक्षण क्यों बर्बाद करते हैं? मैं बच्चा, मैं बच्चा ...;)
— माइक स्ट्रोबेल
1
वास्तव में आपको बच्चे की आवश्यकता नहीं है, यह एक बहुत अच्छा बिंदु है! मैंने उस बारे में नहीं सोचा था, लेकिन अन्य लोगों को परीक्षण करने के लिए गेम सबसे आसान प्रकार के सॉफ़्टवेयर हैं। मुझे लगता है कि कुछ हद तक स्वचालित गेम परीक्षण (इकाई या अन्यथा) की कठिनाई को बंद कर देता है।
— R
3
इकाई परीक्षण आवश्यक रूप से यह सुनिश्चित करने के बारे में नहीं है कि आपका आवेदन पूरी तरह से काम करता है (यानी कार्यात्मक परीक्षण)। यह सुनिश्चित करने के बारे में अधिक है कि भविष्य के परिवर्तन मौजूदा कार्यक्षमता को न तोड़ें। निश्चित रूप से, एक उपयोगकर्ता यह देख सकता है कि स्पेसशिप उल्टा है, लेकिन जब पथिंग एल्गोरिथ्म .001 द्वारा बंद हो जाता है, तो प्रभाव तब तक स्पष्ट नहीं हो सकता जब तक कि गेम 200 घंटे तक नहीं खेला जाता है। कोड के दरवाजे से बाहर जाने से पहले इस तरह की चीजें यूनिट टेस्ट पकड़ सकती हैं।
— वेड विलियम्स
1
खेल उपयोगकर्ताओं को खेलने के लिए प्राप्त करने के लिए सबसे आसान सॉफ्टवेयर हैं , लेकिन खेल! = परीक्षण । अच्छी बग रिपोर्ट प्राप्त करना काफी कठिन है। इसके अलावा, कोड में जहां बग होता है वहां ट्रैकिंग करना, और यह सत्यापित करना कि नए परिवर्तन मौजूदा कोड को नहीं तोड़ते हैं, दोनों स्वचालित परीक्षणों से नाटकीय रूप से लाभान्वित होते हैं।
— उदार

जवाबों:

25

TDD के सिद्धांतों में से एक यह है कि आप कुछ मामलों में TDD को अपने डिजाइन को प्रभावित करते हैं। आप सिस्टम के लिए एक परीक्षण लिखते हैं, फिर उस टेस्ट पास को बनाने के लिए कोड लिखते हैं, निर्भरता को यथासंभव उथले रखते हैं।

मेरे लिए, केवल दो चीजें हैं जो मैं इकाई परीक्षण के भाग के रूप में परीक्षण नहीं करता हूं:

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

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

— जेफ
स्रोत
6
पहला पैराग्राफ कुंजी है। तथ्य यह है कि टीडीडी को आपके कोड को बेहतर ढंग से डिजाइन करने की आवश्यकता है, इसके बिना आपको बस परीक्षण की अनुमति देना होगा। बेशक कई लोग सोचते हैं कि वे डिजाइन के विशेषज्ञ हैं, लेकिन निश्चित रूप से जो लोग अपने स्वयं के कौशल से सबसे अधिक प्रभावित होते हैं, वे आमतौर पर सीखने के लिए सबसे अधिक होते हैं ...
— डैश-टॉम-बैंग
2
मैं इस बात से सहमत नहीं होगा कि कोड को आवश्यक रूप से बेहतर बनाया गया है। मैंने बहुत सारे एबोमिनेशन देखे हैं जहाँ पहले साफ इंटरफ़ेस को खोलना पड़ता था और टेस्टी निर्भरता को इंजेक्ट करने के लिए इनकैप्सुलेशन टूट जाता था।
— काइलोटन
4
मुझे लगता है कि ऐसे उदाहरणों में अधिक होता है जहां परीक्षण पहले से मौजूद कक्षाओं के बजाय अन्य तरीकों से लिखे जाते हैं।
— जेफ
@ कियलोतन जो शायद अनुचित डिजाइन / खराब परीक्षण डिजाइन का एक लक्षण है। साफ परीक्षणों को बनाने के लिए रीफ़ेक्टर और मोक्स का उपयोग, अपने कोड को बदतर स्थिति में हैक न करें; जो होना चाहिए उसके विपरीत है।
— टाइमॉक्सली
2
एनकैप्सुलेशन एक अच्छी बात है, लेकिन जितना महत्वपूर्ण यह समझना है कि यह एक अच्छी बात है। यदि आप सिर्फ निर्भरता और एक बड़े बदसूरत इंटरफ़ेस को छिपाने के लिए इसका उपयोग करते हैं, तो यह बहुत अधिक चिल्लाता है कि हुड के नीचे आपका डिज़ाइन शायद बहुत अच्छा नहीं है। एनकैप्सुलेशन मुख्य रूप से बदसूरत कोड और निर्भरता को छिपाने के बारे में नहीं है, यह मुख्य रूप से आपके कोड को समझने में आसान बनाने के लिए है और जब वह कोड के बारे में तर्क करने की कोशिश कर रहा है तो उपभोक्ता को कम रास्ते मिलेंगे।
— मार्टिन ओढालियस
19

नोएल लोलोपिस ने उस इकाई परीक्षण को उस सीमा तक कवर किया है जो मुझे लगता है कि आप देख रहे हैं:

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

जबकि इस तकनीक के लाभ स्पष्ट हैं, कुछ चीजें हैं जिनसे आपको सावधान रहने की आवश्यकता है:

  • आपके खेल को नियतात्मक होना चाहिए, इसलिए आपको अपने सिस्टम क्लॉक, सिस्टम / नेटवर्क ईवेंट्स, रैंडम नंबर जेनरेटरों के आधार पर ऐसी चीजों से सावधान रहने की जरूरत है, जो नियत रूप से सीडेड नहीं हैं। आदि।
  • सुनहरा छवि उत्पन्न होने के बाद सामग्री परिवर्तन आपकी स्वर्ण छवि के साथ वैध मतभेद पैदा कर सकता है। इसके आसपास होने का कोई तरीका नहीं है - अपनी सामग्री को बदलते समय आपको अपनी सुनहरी छवि को पुन: उत्पन्न करने की आवश्यकता होती है।
— jpaver
स्रोत
+1 यह भी ध्यान देने योग्य है कि इस दृष्टिकोण का मूल्य सीधे "सुनहरी छवि" की लंबाई से संबंधित है: यदि यह लंबे समय तक नहीं है, तो आप आसानी से बग को याद कर सकते हैं; यदि यह बहुत लंबा है, तो आपको बहुत इंतजार करना होगा। यह प्रयास करना महत्वपूर्ण है कि इस मोड में तेजी से परिमाण के एक क्रम को चलाने के लिए गेम प्राप्त करें, सामान्य रनटाइम परिस्थितियों में, समय से दाढ़ी बनाने के लिए। लंघन प्रतिपादन मदद कर सकता है!
— इंजीनियर
9

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

इसी तरह, खेल के अन्य भाग जो संस्थाओं पर भरोसा करते हैं, केवल कार्य करने के लिए घटकों के सबसेट पर निर्भर होना चाहिए। व्यवहार में इसका मतलब है कि आप आमतौर पर इन क्षेत्रों के परीक्षण की सुविधा के लिए कुछ नकली घटकों का मजाक उड़ा सकते हैं या आप परीक्षण उद्देश्यों के लिए आंशिक संस्थाओं की रचना कर सकते हैं। उदाहरण के लिए आप प्रतिपादन और इनपुट घटकों को छोड़ देते हैं, क्योंकि उन्हें भौतिकी का परीक्षण करने की आवश्यकता नहीं है।

अंत में, मैं प्रदर्शन के आसपास की सलाह को अनदेखा करूँगा जो आपको खेल समुदाय के कुछ लोगों से इंटरफेस के बारे में मिलती है। इंटरफेस के साथ कोड को अच्छी तरह से लिखें और यदि आप सड़क के नीचे प्रदर्शन की समस्याओं में भाग लेते हैं तो आप समस्या को हल करने के लिए आसानी से प्रोफाइल, पहचान और रिफ्लेक्टर कर सकते हैं। मैं नोएल की चिंताओं को इंटरफेस के प्रदर्शन प्रभाव या उनके द्वारा जोड़े गए जटिलता के ऊपर से राजी नहीं था।

उस ने कहा, स्वतंत्र रूप से हर छोटी चीज का परीक्षण करने की कोशिश में पानी में मत जाओ। ज्यादातर चीजों की तरह परीक्षण और डिजाइन सही संतुलन बनाने के बारे में हैं।

— एलेक्स शियरर
स्रोत
कृपया ध्यान दें, हालाँकि आप SX के लिए नए नहीं लगते हैं, लेकिन उत्तर दिए जाते हैं और "उपरोक्त दोनों टिप्पणियों" जैसे कुछ कहने की जल्दी नहीं होती। इस समय दो अन्य उत्तरों में से। :)
— टिकट
धन्यवाद, मैंने टिप्पणी करते समय उस बारे में नहीं सोचा था। मैंने तब से व्यक्तिगत टिप्पणियों को चुनने के लिए टिप्पणी को अद्यतन किया है।
— एलेक्स शियरर
3

मैंने सोचा कि मैं ओपी की टिप्पणी का जवाब देने के लिए एक दूसरा उत्तर जोड़ूंगा कि उपयोगकर्ता इकाई परीक्षणों की जगह ले सकता है। मेरा मानना ​​है कि पूरी तरह से गलत है क्योंकि इकाई परीक्षणों का उद्देश्य गुणवत्ता को आश्वस्त करना नहीं है। यदि आप अपने कार्यक्रम की गुणवत्ता सुनिश्चित करने के लिए परीक्षण करना चाहते हैं, तो आपको परिदृश्य परीक्षणों की जांच करनी चाहिए या महान निगरानी में निवेश करना चाहिए।

(महान निगरानी और सेवा के रूप में एक उत्पाद के साथ चलने पर ग्राहक पर कुछ "परीक्षण" करना वास्तव में संभव है, लेकिन आपको एक परिष्कृत प्रणाली की आवश्यकता है जो त्रुटियों को जल्दी से पता लगाता है और जिम्मेदार परिवर्तनों को वापस रोल करता है। सबसे अधिक संभावना है कि यह बहुत अधिक है। एक छोटी सी विकास टीम।)

यूनिट परीक्षण मुख्य लाभ यह है कि वे डेवलपर को बेहतर डिज़ाइन किए गए कोड लिखने के लिए मजबूर करते हैं। परीक्षण का कार्य डेवलपर को चिंताओं को अलग करने और डेटा को एन्क्रिप्ट करने के लिए चुनौती देता है। यह डेवलपर को इंटरफेस और अन्य सार का उपयोग करने के लिए भी प्रोत्साहित करता है ताकि वह केवल एक चीज का परीक्षण करे।

— एलेक्स शियरर
स्रोत
सहमत हूँ, सिवाय इसके कि इकाई परीक्षण डेवलपर्स को अच्छा कोड लिखने के लिए मजबूर नहीं करते हैं। एक और विकल्प है: वास्तव में बुरी तरह से लिखित परीक्षण। आपको अपने कोडर से इकाई परीक्षणों के विचार के लिए प्रतिबद्धता की आवश्यकता है ताकि उन्हें घिस जाना बंद हो सके।
— दस
2
ज़रूर लेकिन यह कोई कारण नहीं है कि बच्चे को नहाने के पानी से बाहर फेंक दिया जाए। उपकरण का उपयोग जिम्मेदारी से करें लेकिन पहले उपकरण का उपयोग करें।
— एलेक्स शियरर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.