ইউনিট পরীক্ষার উত্স মডেল


10

আমার কাস্টম এক্সটেনশনে আমার বেশ কয়েকটি মডেল রয়েছে যা কেবলমাত্র আমার সত্তার অ্যাড / সম্পাদনা ফর্মের মধ্যে কয়েকটি নির্বাচন এবং / অথবা বহুজন নির্বাচনগুলি পূরণ করার উদ্দেশ্যে পরিবেশন করে।
সুতরাং তারা হ'ল ম্যাজেন্টো "উত্স মডেল" বলে।
জড়িত মানগুলি সর্বদা একই থাকে এবং পদ্ধতিগুলি একই জিনিস ফেরত দেয়।
আমি তাদের ইউনিট কিভাবে পরীক্ষা করব? বা আরও ভাল, আমি তাদের জন্য ইউনিট পরীক্ষা লিখতে হবে?
এখানে একটি উদাহরণ।
নিম্নলিখিত শ্রেণীর নামক ক্ষেত্রের 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;
    }
}

উত্তর:


15

এটি দুর্দান্ত থ্রেড, এবং আমি @KAndy এবং @fschmengler- এর উভয় উত্তর পছন্দ করি।
আমি এমন কিছু অতিরিক্ত চিন্তা যুক্ত করতে চাই যা "আমার কি এক্স পরীক্ষা করা উচিত?" এর মতো প্রশ্ন জিজ্ঞাসা করার সময় আমি মূল্যবান বলে মনে করি? বা "এক্স কীভাবে পরীক্ষা করব?"।

কি ভুল হতে পারে?

  • আমি বোবা টাইপো তৈরি করতে পারি (সর্বদা ঘটে)
    এটি সাধারণত কোনও পরীক্ষা লেখার পক্ষে ন্যায়সঙ্গত হয় না।
  • আমি কী কোডটি कोर বা অন্য কোনও মডিউল থেকে আমার প্রয়োজন তা অনুলিপি করব এবং তারপরে এটি আমার প্রয়োজনের সাথে সামঞ্জস্য করব?
    আমি এটি করতে আসলেই খুব বিপজ্জনক জিনিসটি পাই যা প্রায়শই সূক্ষ্ম বাগগুলি ফেলে। এই ক্ষেত্রে, আমি কোনও পরীক্ষা লেখার পক্ষে, যদি এটি খুব ব্যয়বহুল না হয় favor উত্সের মডেলগুলি কনফিগারেশন ভিত্তিক তৈরি করা আসলে তাদের আরও ঝুঁকিপূর্ণ আইএমও করে তুলবে।
  • কোনও আলাদা মডিউল নিয়ে বিরোধ থাকতে পারে?
    এটি প্রায়শই কনফিগারেশন কোডে প্রযোজ্য। এই জাতীয় ক্ষেত্রে আমি একটি ইন্টিগ্রেশন পরীক্ষা করতে চাই যা আমাকে কখন তা ঘটে তা বলে দেয়।
  • ভবিষ্যতে প্রকাশে কি ম্যাগেন্টো এপিআই পরিবর্তন করতে পারে?
    এই ক্ষেত্রে খুব অসম্ভব, কারণ আপনার কোডটি কেবল একটি ইন্টারফেসের উপর নির্ভর করে। তবে আরও কংক্রিট ক্লাস যুক্ত হয় বা যদি আমার কোডটি একটি মূল শ্রেণি প্রসারিত করে, এটি সম্ভাব্য ঝুঁকিপূর্ণ হয়ে ওঠে।
  • একটি নতুন পিএইচপি সংস্করণ আমার কোডটি ভেঙে দিতে পারে। অথবা সম্ভবত আমি আসন্ন বছর পিএইচপি 5.6 সমর্থন করতে চাই।
    আবার এখানে অত্যন্ত অসম্ভাব্য, তবে কিছু ক্ষেত্রে আমি আমাকে সতর্ক করার জন্য একটি পরীক্ষা চাই, ভবিষ্যতে কোডটি যদি বেমানান সিনট্যাক্সটি ব্যবহার করে আমার পরিবর্তন করা উচিত।

কোডটি পরীক্ষা করা কত ব্যয়বহুল?

এর দুটি দিক রয়েছে:

  • একটি পরীক্ষা লিখতে কত পরিমাণ প্রচেষ্টা এবং সময় লাগে
  • আমি নিজে হাতে লিখতে চলেছি কোডের টুকরোটি পরীক্ষা করতে যে পরিমাণ প্রচেষ্টা এবং সময় লাগে।

কিছু অংশের কোডের বিকাশের সময়, আমি কোডটি চালানোর কথা ভেবে থাকি যতক্ষণ না আমি এটি সম্পন্ন না করে বিবেচনা করি। ইউনিট পরীক্ষা দিয়ে এটি অবশ্যই অনেক সহজ।

আপনার ক্ষেত্রে একটি পরীক্ষা লেখার সস্তা সস্তা। এটি বেশি সময় বা প্রচেষ্টা নেয় না। @ কেডি ঠিক আছে যে সমস্ত কোড বজায় রাখা দরকার, তবে আবারও, সমস্ত পরীক্ষা রাখা দরকার হয় না।
এটি একটি উদাহরণ হতে পারে যেখানে আমি ইউনিট পরীক্ষা লিখব, কেবল বোবা ভুল করব না তা পরীক্ষা করতে, এবং ক্লাস শেষ হয়ে গেলে এটি মুছুন। যদি কোনও পরীক্ষা দীর্ঘমেয়াদী মান প্রদান করে না তবে আমি মনে করি সেগুলি মুছে ফেলা অর্থপূর্ণ।

এই প্রশ্নটি লেখার জন্য পরীক্ষার ধরণের চয়ন করার ক্ষেত্রেও গুরুত্বপূর্ণ: উদাহরণ হিসাবে ইউনিট বা সংহতকরণ।

আমি লিখছি কোড টুকরা কত মূল্যবান?

যদি মডিউলটি যে পরিষেবাটির জন্য আমি লিখছি তার কোনও টুকরো যদি প্রয়োজনীয় হয় তবে আমি এটি পরীক্ষা করি না কেন তা তুচ্ছ হোক।
যদি এটি কেবল সামান্য ইউটিলিটি পদ্ধতি হয়, উদাহরণস্বরূপ ইউআই ফোকাস করা, এবং ব্যবসার যুক্তির অংশ না, তবে সম্ভবত না।

কোড পরিবর্তন করার প্রয়োজন হবে?

সময়ের সাথে সাথে আমি টেস্টের কভারেজ দেওয়ার অভ্যস্ত হয়ে পড়েছি, যে অনাবৃত কোড পরিবর্তন করা খুব নিরাপদ বলে মনে হয়। এর মধ্যে সোর্স মডেলটিতে একটি বিকল্প যুক্ত করার মতো সাধারণ জিনিস অন্তর্ভুক্ত রয়েছে তবে কোনও শ্রেণিটিকে অন্য ফোল্ডার / নেমস্পেসে স্থানান্তর করা বা কোনও পদ্ধতির নাম পরিবর্তনের মতো বিষয়গুলিও রয়েছে।
এই ধরনের পরিবর্তনের জন্য পরীক্ষা করা অমূল্য।

এটি কি ডকুমেন্টেশন প্রয়োজন?

কোডটি ব্যবহার করা কতটা কঠিন? আপনার উদাহরণে এটি তুচ্ছ, তবে আরও কিছু জটিল ক্ষেত্রে, অন্যান্য বিকাশকারীদের (বা আমার কয়েক মাসের মধ্যে) ডকুমেন্টেশনের উদ্দেশ্যে পরীক্ষা নেওয়া দুর্দান্ত।

অন্বেষণ এবং শেখা

যদি আমি কিছু কোড নিয়ে কাজ করছি এবং আমি কীভাবে এটি পরীক্ষা করব তা নিশ্চিত নই তবে আমি একটি পরীক্ষা লিখতে খুব মূল্যবান বলে মনে করি। প্রক্রিয়াটি প্রায়শই আমাকে যে বিষয়ে আমি আচরণ করছি তার গভীর ধারণা দেয়।
এটি বিশেষত বিকাশকারীদের ক্ষেত্রে সত্য যারা এখনও নিজেদের পরীক্ষা শেখার বিবেচনা করে।
এটি এমন একটি উদাহরণ যেখানে পরীক্ষার পরে মুছে ফেলাতে এটি বোধগম্য হতে পারে, কারণ এটি প্রদত্ত প্রধান মানটি ছিল শেখা।

শৃঙ্খলা এবং স্ট্রেস

লাল-সবুজ-চুল্লী লুপটি আটকে থাকা আমাকে দ্রুত যেতে সাহায্য করে। বিশেষত চাপের মধ্যে এটি সত্য। সুতরাং কোডের কিছু অংশ যদি সত্যিই পরীক্ষার যোগ্য না হয় তবে আমি এখনও টিডিডি অনুসরণ করতে পারি, বিশেষত যদি কোডটি পরীক্ষা করা তুচ্ছ হয়।
এটি আমাকে প্রবাহে রাখে এবং সজাগ রাখে।

কী এবং কীভাবে পরীক্ষা করবেন?

এছাড়াও বিবেচনা করুন যে আপনি পরীক্ষাটি বিভিন্ন ভিন্ন গ্রানুলারিতে লিখতে পারেন।

  • সঠিক ফেরতের মান পরীক্ষা করা হচ্ছে।
    এটি একটি অত্যন্ত কঠোর পরীক্ষা হবে যা প্রতিটি পরিবর্তনের সাথে সামঞ্জস্য করতে হবে। আপনি কি পরীক্ষাটি বিরতিতে চান, উদাহরণস্বরূপ, যদি ফিরতি অ্যারে আইটেমগুলির ক্রম পরিবর্তন হয়?
  • রিটার্ন মান কাঠামো পরীক্ষা করা হচ্ছে।
    উত্স মডেলটির জন্য এটি প্রতিটি উপ-অ্যারে দুটি রেকর্ড হিসাবে পরীক্ষা করতে পারে, একটিতে একটি labelএবং একটি valueকী দিয়ে।
  • ক্লাসের সরঞ্জামগুলি পরীক্ষা করা হচ্ছে ArrayInterface
  • শ্রেণি পরীক্ষা করা প্রদান করে getOptions()যদিও সেই পদ্ধতিটি প্রয়োগ করা ইন্টারফেসের অংশ না।

পরীক্ষা করা যায় এমন প্রতিটি সম্ভাব্য জিনিসের জন্য মূল্য, রক্ষণাবেক্ষণযোগ্যতা এবং ব্যয় বিবেচনা করুন।

সারসংক্ষেপ

সংক্ষিপ্তসার হিসাবে: কোনও কোডের কিছু অংশ পরীক্ষা করা উচিত কিনা সে প্রশ্নের কোনও সত্যিকারের একক উত্তর নেই। উত্তরগুলি প্রতিটি বিকাশকারীদের পরিস্থিতি অনুসারে আলাদা হবে।


2
দুর্দান্ত উত্তর! আমি "পরীক্ষাগুলি যখন তারা আর মান দেয় না" অংশটি হাইলাইট করতে চাই - কখনও কখনও পুরানো পরীক্ষাগুলি যা প্রাথমিক বিকাশকালে সহায়তা করেছিল, দীর্ঘমেয়াদী পথে পাচ্ছে।
ফ্যাবিয়ান শেমংলার

1
আমার সবে সন্দেহ আছে এমন 2 টি প্রশ্নের উত্তর আপনিই দিয়েছিলেন। ধন্যবাদ
মারিয়াস

6

আমার মতে, "উত্স মডেলগুলির জন্য ইউনিট পরীক্ষা লিখুন, হ্যাঁ বা না" এর কোনও সাধারণ উত্তর নেই

আমি উত্স মডেলগুলির জন্য ইউনিট পরীক্ষাগুলি লিখেছি, তবে সেগুলি গতিশীল উত্স মডেলগুলি ছিল যা বাহ্যিক ডেটা এনেছিল এবং এটি সেখানে মোটামুটি বোঝায়।

উত্স মডেলগুলির জন্য যা মহিমান্বিত অ্যারে ছাড়া কিছুই নয় (যেমন আপনার উদাহরণ হিসাবে), আমি ইউনিট পরীক্ষাগুলি লিখতে বিরক্ত করব না। তবে কোনও উপায়ে আপনাকে নিশ্চিত করতে হবে যে আপনি কোনও ভুল করেননি। বেশ কয়েকটি বিকল্প রয়েছে:

  1. ইউনিট পরীক্ষা
  2. ইন্টিগ্রেশন পরীক্ষা
  3. ম্যানুয়ালি কনফিগারেশন দেখুন

আপনি কি টিডিডি অনুসরণ করছেন? তারপরে (1) এবং (2) বা উভয়ের মধ্যে বেছে নিন। অন্যথায়, (2) এবং (3) এর মধ্যে চয়ন করুন।


আপনি যদি সিস্টেম কনফিগারেশন বিকল্পগুলির জন্য উত্স মডেলগুলি ব্যবহার করেন, একটি ইন্টিগ্রেশন টেস্ট (আপনার সমস্ত কনফিগারেশন বিকল্পের জন্য একটি পরীক্ষা) কনফিগারেশন বিভাগটি রেন্ডার করতে পারে এবং <select>উপাদানগুলি উপস্থিত রয়েছে এবং প্রত্যাশিত মানগুলি অন্তর্ভুক্ত রয়েছে কিনা তা পরীক্ষা করতে পারে। মনে রাখবেন যে এটি একটি নির্দিষ্ট ক্লাসের পরীক্ষা করার বিষয়ে নয় বরং এটি পরীক্ষা করা যে সমস্ত কিছু সঠিকভাবে বাঁধা আছে।


এবং যেমন ক্যান্ডি বলেছেন, আদর্শভাবে আপনার এত বেশি বয়লারপ্লেটের প্রয়োজন হবে না, কেবল একটি বেস ক্লাস প্রসারিত করুন যা ইতিমধ্যে পরীক্ষিত ইউনিট এবং কোনও সম্পত্তিকে ওভাররাইড করে বা বাহ্যিক কনফিগারেশনে মানগুলি সংজ্ঞায়িত করে।

এই পরিস্থিতিতে, কংক্রিট বাস্তবায়নের জন্য ইউনিট পরীক্ষাগুলি কোনও অতিরিক্ত মান সরবরাহ করে না। আপনার যদি এই ক্লাসগুলির অনেকগুলি ArraySourceথাকে তবে ম্যাগেন্টো এটি সরবরাহ না করা অবধি নিজেই বেস বর্গ লেখার পক্ষে ভাল ধারণা হতে পারে ।


এই জাতীয় বেস শ্রেণীর সাহায্যে আপনার উত্সের মডেলটি দেখতে পারা যায়:

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

নিশ্চিত করার জন্য ধন্যবাদ. আমি আমার গৌরবময় অ্যারেগুলিকে একটি কনফিগারযোগ্য বিকল্প তালিকায় পরিণত করার চেষ্টা করব, তবে একই মডেলগুলিতে ঠিক কী এন বিকল্প থাকবে? একটি "স্থিতি" উত্স মডেল মত।
মারিয়াস

আমি দেখতে পাচ্ছি না যে "স্ট্যাটাস" উত্সের মডেলটি আপনার "লেখকের ধরণ" উদাহরণের চেয়ে আলাদা হবে কীভাবে
ফ্যাবিয়ান শেমংলার

কারণ আমি উদাহরণস্বরূপ সক্ষম সত্তাগুলিকে ফিল্টার করতে ফ্রন্টএন্ডে 0 এবং 1 এর মানগুলি (শ্রেণি ধ্রুবক হিসাবে) ব্যবহার করতে পারি। আমি এই ক্ষেত্রে বলতে চাইছি বিকল্পগুলির মানগুলির পিছনে যুক্তি রয়েছে। তারা কেবল key=>valueজোড়া নয়।
মারিয়াস

কিন্তু এই যুক্তি উত্স মডেল অংশ না, তাই না? তার মানে এখানে কিছু আসে যায় না। আপনার কাছে এখনও অন্য জায়গায় ব্যবহারের জন্য ধ্রুবক থাকবে। আমি একটি উদাহরণ যোগ করেছি কীভাবে আমি এই জাতীয় ইমপ্লিমেন্টটি ব্যবহার করব।
ফ্যাবিয়ান শেমঙ্গলার

5

আমি তাদের ইউনিট কিভাবে পরীক্ষা করব?

আমার মনে হয় আপনার উচিত হবে না।

সিস্টেম বৃদ্ধি সমর্থন এবং রক্ষণাবেক্ষণ খরচ কোড যোগ করুন কিন্তু পরীক্ষার প্রক্রিয়া হওয়া উচিত চর্বিহীন

এই কোডের বেশি থাকা উচিত নয়। আমি বিশ্বাস করি যে ম্যাজেন্টোর চেয়ে আলাদা জায়গায় ব্যবহারের জন্য অপশনগুলির সেটগুলি সংজ্ঞায়নের এক সাধারণ জবাবদিহি উপায় হওয়া উচিত। এবং এই শ্রেণীর জন্য আপনার লেখার পরীক্ষার অনীহা আমাকে খারাপ কোডের গন্ধ দেখাচ্ছে


1
ধন্যবাদ। সুতরাং আপনি বলছেন যে এই বিকল্পগুলি হার্ড-কোডেড হওয়া উচিত নয় তবে একটি কনফিগার ফাইল (উদাহরণস্বরূপ di.xML) থেকে আসা উচিত। আমি এটা করতে পারি। তবে স্ট্যাটাস সোর্স মডেলগুলির ক্ষেত্রেও কি একই সত্য? আমি বোঝাতে চাইছি, যদি আমার উপরের মত একই বর্গ থাকে তবে কেবল স্থিতি সক্ষম এবং অক্ষম (1,0) সহ আমার কি একই কনফিগার পদ্ধতিটি ব্যবহার করা উচিত? যদি হ্যাঁ, আমি বলতে চাই যে এটি আমার জন্য ওভার ইঞ্জিনিয়ারিংয়ের মতো সিলমোহর করে।
মারিয়াস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.