क्या परीक्षण-संचालित विकास मुझे SOLID का पालन करने के लिए मजबूर करता है?

15

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

क्या TDD डेवलपर्स को केवल इकाई परीक्षण लिखने की तुलना में अधिक सक्रिय रूप से SOLID का पालन करने के लिए मजबूर करता है?

unit-testing tdd solid

— SiberianGuy
स्रोत

1

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

— यम मार्कोविच

1

रतालू: मैं असहमत हूँ, टीडीडी इकाई परीक्षण लिखने के बारे में नहीं है। TDD हाथ में समस्या के लिए एक न्यूनतम जटिल और सही समाधान के बारे में है। टेस्ट प्रक्रिया का सिर्फ एक उप-उत्पाद हैं

— अमित वाधवा

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

— यम मार्कोविच

24

सबसे पहले, TDD आपको सख्ती से SOLID कोड लिखने के लिए मजबूर नहीं करता है । यदि आप चाहते थे तो आप TDD कर सकते थे और एक बड़ी गड़बड़ बना सकते थे।

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

यदि आप पहले से ही ठोस सिद्धांतों के बारे में जानते हैं, तो टीडीडी आपको उनके बारे में सोचने और उन्हें सक्रिय रूप से उपयोग करने के लिए प्रोत्साहित करेगा।

यह कहा गया है, यह जरूरी नहीं है कि यह सभी पत्रों को SOLID में शामिल न करे , लेकिन यह आपको कम से कम आंशिक रूप से SOLID कोड लिखने के लिए प्रोत्साहित और प्रोत्साहित करता है, क्योंकि यह ऐसा न करने के परिणामों को तुरंत दिखाई देता है और कष्टप्रद बनाता है।

उदाहरण के लिए:

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

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

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

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

— यम मारकोविच
स्रोत

इसके अलावा जब तक आप ओपन / बंद और लिस्कोव प्रतिस्थापन का पालन नहीं करते हैं, तब तक आपके मोक्स बाद में टूट जाएंगे। इसलिए भले ही टीडीडी आपको ओसीपी और एलएसपी लागू करने में मदद न करे लेकिन बनाए गए परीक्षण आपको बताएंगे कि आप इसे कब तोड़ते हैं। सामान्य रूप से परीक्षण का अधिक प्रभाव, लेकिन अभी भी ध्यान देने योग्य है।

— जोनास शूबर्ट एर्लडसन

9

नहीं

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

— dietbuddha
स्रोत

2

जब मैंने TDD करना शुरू किया, तो SOLID सिद्धांतों की मेरी समझ का विस्तार हुआ। जैसे ही मैंने यह सोचना शुरू किया कि कैसे निर्भरता का मजाक उड़ाया जाए, मुझे पता चला कि कोड बेस में हर घटक का संभावित वैकल्पिक कार्यान्वयन था। और एक साधारण सार्वजनिक एपीआई का परीक्षण करना कितना आसान है।

इसने अधिकांश डिजाइन पैटर्नों की अधिक मजबूत समझ प्रदान की। खासकर स्ट्रेटेजी पैटर्न।

— हीथ लिली
स्रोत

0

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

TDD और ठोस सिद्धांतों के बीच का संबंध विवादित है (ऊपर निष्कर्ष के साथ) "टेस्ट ड्रिवेन डिवेलपमेंट इस डिज़ाइन - द लास्ट वर्ड ऑन टीडीडी" नाम के इस महान हेंसेल्स्मिनुट पॉडकास्ट में है ।

— DaveFar
स्रोत