इकाई परीक्षण स्रोत मॉडल

Question

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

<?php
namespace Sample\News\Model\Author\Source;

use Magento\Framework\Option\ArrayInterface;

class Type implements ArrayInterface
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;

    /**
     * Get options
     *
     * @return array
     */
    public function toOptionArray()
    {
        $_options = [
            [
                'value' => '',
                'label' => ''
            ],
            [
                'value' => self::COLLABORATOR,
                'label' => __('Collaborator')
            ],
            [
                'value' => self::EMPLOYEE,
                'label' => __('Employee')
            ],
        ];
        return $_options;
    }

    /**
     * get options as key value pair
     *
     * @return array
     */
    public function getOptions()
    {
        $_tmpOptions = $this->toOptionArray();
        $_options = [];
        foreach ($_tmpOptions as $option) {
            $_options[$option['value']] = $option['label'];
        }
        return $_options;
    }
}

Answer 1

यह एक महान धागा है, और मुझे @KAndy और @fschmengler दोनों के उत्तर पसंद हैं।
मैं कुछ अतिरिक्त विचार जोड़ना चाहूंगा जो मुझे एक प्रश्न पूछने पर मूल्यवान लगता है जैसे "क्या मुझे एक्स का परीक्षण करना चाहिए?" या "मुझे एक्स का परीक्षण कैसे करना चाहिए?"।

क्या गलत हो सकता था?

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

कोड का परीक्षण करना कितना महंगा है?

इसके दो पहलू हैं:

• परीक्षण लिखने के लिए प्रयास और समय की मात्रा
• कोड के टुकड़े का परीक्षण करने के लिए प्रयास और समय की मात्रा मैं मैन्युअल रूप से लिखने वाला हूं।

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

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

यह प्रश्न लिखने के लिए परीक्षण के प्रकार को चुनने के संदर्भ में भी महत्वपूर्ण है: उदाहरण के लिए इकाई या एकीकरण।

मैं जो कोड लिख रहा हूं, वह कितना मूल्यवान है?

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

क्या कोड को बदलना होगा?

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

क्या इसे प्रलेखन की आवश्यकता है?

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

अन्वेषण और अधिगम

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

अनुशासन और तनाव

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

क्या और कैसे परीक्षण करें?

यह भी विचार करें कि आप परीक्षण को बहुत अलग ग्रैन्युलैरिटी में लिख सकते हैं।

• सटीक रिटर्न मान का परीक्षण।
  यह एक बहुत ही कठोर परीक्षण होगा जिसे हर परिवर्तन के साथ समायोजित करना होगा। क्या आप चाहते हैं कि परीक्षण टूट जाए, उदाहरण के लिए, यदि रिटर्न ऐरे में वस्तुओं का क्रम बदलता है?
• रिटर्न वैल्यू की संरचना का परीक्षण।
  स्रोत मॉडल के लिए यह प्रत्येक उप-सरणी को दो रिकॉर्ड के रूप में जाँच सकता है, एक के साथ labelऔर एक के साथvalue कुंजी के ।
• क्लास के इम्प्लाइज़ की जाँच करना ArrayInterface ।
• कक्षा का परीक्षण प्रदान करता है, getOptions()भले ही वह तरीका कार्यान्वित इंटरफ़ेस का हिस्सा न हो।

प्रत्येक संभावित चीज के लिए जिसका परीक्षण किया जा सकता है, मूल्य, रखरखाव और लागत पर विचार करें।

सारांश

इसे सम्‍मिलित करने के लिए: किसी प्रश्न का कोई सही एकल उत्तर नहीं है कि क्या किसी कोड का परीक्षण किया जाना चाहिए या नहीं। परिस्थितियों के आधार पर प्रत्येक डेवलपर के लिए उत्तर अलग-अलग होगा।

Comments

बहुत बढ़िया जवाब! मैं "डिलीट टेस्ट्स को तब हिगिनेट करना चाहता हूं जब वे वैल्यू अब उपलब्ध नहीं कराते हैं" भाग - कभी-कभी पुराने टेस्ट जो शुरुआती डेवलपमेंट के दौरान मदद करते थे, वे अभी लॉन्ग-टर्म तरीके से मिल रहे हैं।

— फेबियन शेंगलर

आपने सिर्फ 2 अन्य सवालों के जवाब दिए, जिनके बारे में मुझे संदेह था। धन्यवाद

— मेरियस

Answer 2

मेरी राय में, "स्रोत मॉडल के लिए इकाई परीक्षण लिखने के लिए कोई सामान्य उत्तर नहीं है, हाँ या नहीं"

मैंने स्रोत मॉडल के लिए यूनिट परीक्षण लिखा है, लेकिन वे गतिशील स्रोत मॉडल थे जो बाहरी डेटा प्राप्त करते थे और वहां यह कुल अर्थ बनाता है।

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

1. अध्याय परीक्षा
2. जोड़ने का परीक्षण
3. कॉन्फ़िगरेशन को मैन्युअल रूप से देखें

क्या आप टीडीडी का पालन कर रहे हैं? फिर (1) और (2), या दोनों के बीच चुनें। अन्यथा, (2) और (3) के बीच चुनें।

---

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

---

और जैसा कि @KAndy ने कहा, आदर्श रूप से आपको उतनी बॉयलरप्लेट की आवश्यकता नहीं होगी, बस एक बेस क्लास का विस्तार करें जो पहले से ही यूनिट परीक्षण किया गया है और एक संपत्ति को ओवरराइड करता है या बाहरी कॉन्फ़िगरेशन में मूल्यों को परिभाषित करता है।

उस परिदृश्य में, ठोस कार्यान्वयन के लिए इकाई परीक्षण कोई अतिरिक्त मूल्य प्रदान नहीं करते हैं। यदि आपके पास इनमें से कई कक्षाएं हैं, तो ArraySourceअपने आप को बेस क्लास लिखना एक अच्छा विचार हो सकता है , जब तक कि Magento इसे प्रदान नहीं करता है।

---

इस तरह के आधार वर्ग के साथ, आपका स्रोत मॉडल इस तरह दिख सकता है:

class Type extends ArraySource
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;
    protected $elements = [
        self::COLLABORATOR => 'Collaborator',
        self::EMPLOYEE     => 'Employee',
    ];
    protected $withEmpty = true;
    protected $translate = true;
}

Comments

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

— Marius

मैं यह नहीं देखता कि "स्थिति" स्रोत मॉडल आपके "लेखक प्रकार" उदाहरण के लिए कैसे भिन्न होगा

— Fabian Schmengler

क्योंकि मैं सक्षम संस्थाओं के उदाहरण के लिए फ़िल्टर करने के लिए फ़्रंटेंड पर मान 0 और 1 (वर्ग स्थिरांक के रूप में) का उपयोग कर सकता हूं। मेरा मतलब है कि इस मामले में, विकल्प मूल्यों के पीछे तर्क है। वे सिर्फ key=>valueजोड़े नहीं हैं ।

— Marius

लेकिन यह तर्क स्रोत मॉडल का हिस्सा नहीं है, है ना? इसका मतलब है कि यहां कोई फर्क नहीं पड़ता। आपके पास अभी भी अन्य स्थानों पर उपयोग करने के लिए स्थिरांक होंगे। मैंने एक उदाहरण जोड़ा कि मैं इस तरह के निहितार्थ का उपयोग कैसे करूंगा।

— फाबियान शेंगलर

Answer 3

मुझे यूनिट का परीक्षण कैसे करना चाहिए?

मुझे लगता है कि आपको नहीं करना चाहिए।

समर्थन बढ़ाने और रखरखाव की लागत बढ़ाने के लिए कोड जोड़ें लेकिन परीक्षण की प्रक्रिया LEAN होनी चाहिए ।

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

Comments

धन्यवाद। तो आप कह रहे हैं कि ये विकल्प हार्ड-कोडेड नहीं होने चाहिए लेकिन एक कॉन्फिग फ़ाइल (उदाहरण के लिए di.xml) से आते हैं। मैं ऐसा कर सकता हूँ। लेकिन क्या स्टेटस सोर्स मॉडल के लिए भी यही सच है? मेरा मतलब है, अगर मेरे पास ऊपर के समान वर्ग है, लेकिन केवल स्थिति सक्षम और अक्षम है (1,0) तो क्या मुझे उसी कॉन्फ़िगरेशन दृष्टिकोण का उपयोग करना चाहिए? अगर हां, तो मैं कहना चाहता हूं कि यह मेरे लिए ओवर-इंजीनियरिंग पसंद है।

— मारियस