परीक्षण-विकास विकास खेल विकास में एक सामान्य दृष्टिकोण है?

Question

मैं उत्सुक हूं क्योंकि सभी TDD उदाहरण मैंने वेब प्रोग्रामिंग से संबंधित है। और यदि यह सामान्य दृष्टिकोण नहीं है, तो ऐसा क्यों नहीं है?

Answer 1

टीडीडी सॉफ्टवेयर डेवलपर्स द्वारा एक पसंदीदा दृष्टिकोण बन गया है जो अपने पेशे के बारे में गंभीर हैं। [IEEE:TDD] दृष्टिकोण के लाभ महत्वपूर्ण हैं, और लागत तुलना करके कम हैं। [The Three Laws of TDD]

कोई सॉफ्टवेयर डोमेन नहीं है जिसके लिए टीडीडी अनुचित है, या अप्रभावी है। हालांकि, ऐसे डोमेन हैं जिनमें यह चुनौतीपूर्ण है। गेमिंग इनमें से एक है।

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

अब सब लोग रोते हैं और कहते हैं: "अंकल बॉब कहते हैं: 'यूआई के लिए टीडीडी मत करो' 'मुझे यह कहना है। तथ्य यह है कि यूआई के लिए शुद्ध टीडीडी करना मुश्किल है इसका मतलब यह नहीं है कि आप लगभग बाकी सब कुछ के लिए शुद्ध टीडीडी नहीं कर सकते हैं। अधिकांश गेमिंग एल्गोरिदम के बारे में है, और आप उन एल्गोरिदम के साथ टीडीडी का उपयोग अपने दिल की खुशी के लिए कर सकते हैं। यह सच है, विशेष रूप से गेमिंग में, कि उनमें से कुछ एल्गोरिदम यूआई की तरह ही आपको पसंद करते हैं, और संभवतः पहले का परीक्षण करने के लिए उपयुक्त नहीं हैं। लेकिन वहां कई अन्य एल्गोरिदमिक कोड हैं जो पहले परीक्षण लिखे जा सकते हैं और चाहिए।

यहां की चाल single responsibility principle (SRP) का पालन करना है और उन प्रकार के कोड को अलग करना है जिन्हें आप तय करना चाहते हैं, जो कि निर्धारक हैं। अपने यूआई के साथ आसान-से-परीक्षण एल्गोरिदम न रखें। अपने सट्टा कोड को अपने गैर-सट्टा कोड के साथ मिश्रित न करें। कारणों को बदलने के लिए चीजों को रखें बी कारणों से भिन्न चीजों से अलग।

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

लेखन के साथ समस्या "तथ्य के बाद" यह है कि अक्सर कोड इतना जोड़ा जाता है कि सर्जिकल प्रकारों को लिखना मुश्किल है परीक्षण जो सबसे उपयोगी हैं। तो यदि आप इस तरह के कोड लिख रहे हैं जो पहले का परीक्षण करना मुश्किल है, तो आपको dependency inversion principle (DIP), और open/closed principle (ओसीपी) का पालन करने के लिए सावधानी बरतनी चाहिए ताकि कोड को तथ्य के बाद परीक्षण करने के लिए पर्याप्त रूप से डीकॉप्ल किया जा सके।

Answer 2

टीडीडी वास्तव में कहीं भी 'सामान्य' दृष्टिकोण नहीं है क्योंकि यह अभी भी अपेक्षाकृत नया है और सार्वभौमिक रूप से समझा या स्वीकार नहीं किया गया है। यह कहना नहीं है कि कुछ दुकानें अब इस तरह से काम नहीं करती हैं, लेकिन मैं इस बिंदु पर किसी का भी इस्तेमाल करने के लिए अभी भी हैरान हूं।

Answer 3

भीतर से खेलों में an article यूनिट परीक्षण के उपयोग, विशेष रूप से गेम के संबंध में इकाई परीक्षण की सीमाओं और एक स्वचालित कार्यात्मक परीक्षण सर्वर की चर्चा करने के बारे में चर्चा करने के लिए चर्चा की गई है।

Answer 4

अधिकांश गेम डेवलपर्स आधुनिक विकास प्रथाओं के संदर्भ में बिल्कुल इसके साथ नहीं हैं। शुक्र है।

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

तो अच्छे गेम डेवलपर्स यह स्वाभाविक रूप से करते हैं। बस स्पष्ट रूप से नहीं।

Answer 5

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

• सांस्कृतिक। प्रोग्रामर रूढ़िवादी हैं, गेम प्रोग्रामर दोगुनी हैं।
• प्रैक्टिकल। टीडीडी समस्या डोमेन (बहुत अधिक चलती भागों) के लिए बहुत अच्छी तरह से फिट नहीं है।
• क्रंचोलॉजिकल। पर्याप्त समय नहीं है।

टीडीडी प्रतिमान एप्लिकेशन डोमेन में सबसे अच्छा काम करता है जो बहुत ही सतर्क नहीं हैं, या कम से कम जहां चलती हिस्से एक ही समय में सभी एक साथ नहीं चल रहे हैं, इसे बोलने के लिए।

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

टीडीडी एक उपयोगी उपकरण हो सकता है, लेकिन चांदी की बुलेट के रूप में इसकी स्थिति जो सर्वव्यापी-जब-बनाने-एक-प्रणाली को संदिग्ध होना चाहिए। विकास परीक्षण द्वारा संचालित नहीं किया जाना चाहिए, लेकिन कारण से। आरडीडी हालांकि एक क्रोधित शब्दकोष है - यह पकड़ नहीं पाएगा। ;)

Answer 6

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

यह वही बात नहीं है जैसे गेम की गंभीर जांच की आवश्यकता है।

Answer 7

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

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

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

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

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

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

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

Answer 8

सरल उत्तर "नहीं" है, टीडीडी खेल विकास में एक सामान्य दृष्टिकोण नहीं है। कुछ लोग हाईमून और नील लोपिस को काउंटर-उदाहरण के रूप में इंगित करेंगे, लेकिन यह एक बड़ा उद्योग है और वे एकमात्र ऐसे लोग हैं जिन्हें मैं जानता हूं जिन्होंने टीडीडी को पूरी तरह से गले लगा लिया है। मुझे यकीन है कि कुछ भी हैं, लेकिन वे केवल मुझे जानते हैं (और मैं 5 वर्षों तक उद्योग में रहा हूं)।

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

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

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

मेरी राय में उच्च स्तर के व्यवहार का परीक्षण करते हुए निम्न स्तर के कोड परीक्षण करने के लिए यूनिट द्वारा सभ्य परीक्षण कवरेज प्राप्त करना संभव है। मुझे लगता है (उम्मीद है कि अन्य स्टूडियो भी एक समान दृष्टिकोण ले रहे हैं।

यदि टीडीडी की मेरी राय कुछ हद तक संदिग्ध लगता है क्योंकि ऐसा है। मैं अभी भी इसके बारे में बाड़ पर कुछ हद तक हूँ। जबकि मुझे कुछ फायदे (रिग्रेशन टेस्टिंग, कोड से पहले डिज़ाइन पर जोर दिया जाता है), इसे लागू करना और प्री-मौजूदा कोडबेस के साथ काम करते समय इसे लागू करना सिरदर्द के लिए नुस्खा जैसा लगता है।