(কেন) একটি ইউনিট পরীক্ষা নির্ভরতা পরীক্ষা না করা গুরুত্বপূর্ণ?

Question

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

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

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

এর অন্য দিকটি কী? ইউনিট পরীক্ষাও তার নির্ভরতা পরীক্ষা না করে সত্যই গুরুত্বপূর্ণ? যদি তাই হয় তবে কেন?

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

Comments

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

— এস.লট

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

— dsimcha

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

— এস.লট

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

— dsimcha

আপনি যে কোনও পার্থক্য তৈরি করছেন তা স্পষ্ট করতে আপনার প্রশ্ন আপডেট করার বিষয়ে বিবেচনা করুন । মন্তব্যের ক্রম সংহত করা কঠিন difficult প্রশ্নটি স্পষ্ট করে ফোকাস করতে আপডেট করুন update

— এস.লট

Answer 1

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

আমাদের পণ্যের জন্য: আমাদের ইউনিট পরীক্ষাগুলি প্রতিটি বিল্ডের সাথে সেকেন্ড সময় নিয়ে চালিত হয়। আমাদের ইন্টিগ্রেশন পরীক্ষার একটি উপসেট 10 মিনিট সময় নেয় প্রতিটি চেক ইন দিয়ে চলে। আমাদের পূর্ণ সংহতকরণ স্যুট প্রতি রাতে চালানো হয়, 4 ঘন্টা সময় নেয় taking

Comments

ভবিষ্যতে রক্ষণাবেক্ষণের সময় সিস্টেমে তাদের পুনঃপ্রবর্তন রোধ করতে আবিষ্কার করা এবং স্থির বাগগুলি কভার করতে রিগ্রেশন টেস্টগুলি সম্পর্কে ভুলে যাবেন না।

— RBerteig

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

— ডানিডাকর

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

— জেফ্রি ফাউস্ট

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

— রিকার্ডো রডরিগস

এটি কেবল দ্রুত হওয়া সম্পর্কে নয়, বরং অত্যন্ত ক্লান্তিকর বা নিয়ন্ত্রণহীন হওয়ার কথা নয়, কল্পনা করুন, আপনি যদি তা না করেন তবে আপনার উপহাসের মৃত্যুদণ্ড কার্যকর হতে চলেছে দ্রুততর। আপনি নিজের ইউনিটের 10 টি নির্ভরতা উপহাস করার কথা ভাবুন যদি আপনি আরও ঠাট্টা-বিদ্রূপের দিকে ঠেলা দেন তবে ধরা যাক যে 10 নির্ভরতাগুলির মধ্যে 1 টি অনেক জায়গায় ব্যবহৃত হয় এবং এর নিজস্ব নিজস্ব 20 টি নির্ভরতা রয়েছে, তাই আপনাকে বেশিরভাগ জায়গায় নকলভাবে + 20 টি নির্ভরতা করতে হবে। চূড়ান্ত-এপিআই পয়েন্টে আপনাকে উপহাস করতে হবে - উদাহরণস্বরূপ ডাটাবেস, যাতে আপনাকে এটি পুনরায় সেট করতে না হয় এবং আপনি যেমন বলেছিলেন তত দ্রুত

— FantomX1

Answer 2

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

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

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

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

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

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

---

যতদূর অভ্যন্তরীণ নির্ভরতা সম্পর্কিত বিষয়গুলি জিনিসগুলি কিছুটা ঘোলাটে হয়ে যায়। আমি এটি সম্পর্কে যেভাবে ভাবতে চাই তা হ'ল আমি আমার ক্লাসকে ভুল কারণে পরিবর্তন থেকে যতটা সম্ভব রক্ষা করতে চাই। আমার যদি এই জাতীয় কিছু সেটআপ থাকে ...

public class MyClass 
{
    private SomeClass someClass;
    public MyClass()
    {
        someClass = new SomeClass();
    }

    // use someClass in some way
}

আমি সাধারণত যত্নশীল না কিভাবে SomeClassতৈরি হয়। আমি শুধু এটি ব্যবহার করতে চাই। যদি সামার ক্লাস পরিবর্তন হয় এবং এখন কনস্ট্রাক্টরের প্যারামিটারগুলির প্রয়োজন হয় ... এটি আমার সমস্যা নয়। এটি মেটানোর জন্য আমার মাই ক্লাস পরিবর্তন করা উচিত নয়।

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

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

কনস্ট্রাক্টরে স্যামক্লাসের উদাহরণ স্বীকার করতে মাইক্লাসকে পুনরায় লেখাই আমাকে সামারক্লাসের একটি জাল উদাহরণ তৈরি করতে সক্ষম করে যা আমার মানটি ফেরত দেয় (হয় একটি বিদ্রূপের কাঠামোর মাধ্যমে বা ম্যানুয়াল মক দিয়ে)। আমি সাধারণত না আছে এই ক্ষেত্রে একটি ইন্টারফেস পরিচয় করিয়ে দিতে। এটি করা বা না করা বিভিন্ন উপায়ে আপনার পছন্দের ভাষা দ্বারা নির্ধারিত একটি ব্যক্তিগত পছন্দ (উদাহরণস্বরূপ ইন্টারফেসগুলি সি # তে বেশি সম্ভাবনা রয়েছে তবে আপনার অবশ্যই রুবিতে একটি প্রয়োজন হবে না)।

Comments

+1 দুর্দান্ত উত্তর, কারণ বাহ্যিক নির্ভরতা এমন একটি মামলা যা আমি কখন আসল প্রশ্নটি লিখি তা নিয়ে ভাবছিলাম না। আমি প্রতিক্রিয়াতে আমার প্রশ্ন পরিষ্কার করেছি। সর্বশেষ সম্পাদনা দেখুন See

— dsimcha

@ ডিডিমচা আমি তার উত্তরটি আরও বিস্তারিতভাবে জানাতে প্রসারিত করেছি। আশা করি এটা সাহায্য করবে.

— অ্যাডাম শিখুন

অ্যাডাম, আপনি কি এমন ভাষা বলতে পারবেন যেখানে "যদি সামার ক্লাস পরিবর্তন হয় এবং এখন কনস্ট্রাক্টরের প্যারামিটার প্রয়োজন ... আমার মাই ক্লাস পরিবর্তন করা উচিত নয়" সত্য? দুঃখিত, এটি একটি অস্বাভাবিক প্রয়োজনীয়তা হিসাবে আমার দিকে ঝাঁপিয়ে পড়ে। আমি মাইক্লাসের জন্য ইউনিট পরীক্ষার পরিবর্তন না করে দেখতে পেলাম, তবে মাইক্লাস পরিবর্তন করতে হবে না ... বাহ!

@ মোজ আমি যা বোঝাতে চেয়েছি তা হ'ল সামার ক্লাসটি তৈরির পথে যদি মাইক্র্লাসটি অভ্যন্তরীণভাবে তৈরির পরিবর্তে স্যামক্লাসকে ইনজেক্ট করা হয় তবে পরিবর্তন করতে হবে না। সাধারণ পরিস্থিতিতে মাইক্লাসের সামার ক্লাসের জন্য সেটআপের বিশদ সম্পর্কে যত্ন নেওয়া উচিত নয়। যদি সামার ক্লাসের ইন্টারফেস পরিবর্তিত হয়, তবে হ্যাঁ ... মাইক্লাস এটি ব্যবহার করার যে কোনও পদ্ধতিতে প্রভাবিত হলে এখনও তাকে সংশোধন করতে হবে।

— অ্যাডাম শিখুন

আপনি যদি মাইক্লাস পরীক্ষা করার সময় সোমারক্লাসকে বিদ্রূপ করেন, আপনি কীভাবে সনাক্ত করবেন যে মাইক্লাস সামারক্লাসটি ভুলভাবে ব্যবহার করছে বা পরিবর্তিত হতে পারে এমন সামারক্লাসের একটি অনির্ধারিত কোয়ার্কের উপর নির্ভর করে?

— namey

Answer 3

ইউনিট বনাম ইন্টিগ্রেশন পরীক্ষার সমস্যাটি বাদ দিয়ে, নিম্নলিখিতটি বিবেচনা করুন।

ক্লাস উইজেটের ক্লাস থিংগামজিগ এবং হোয়াটসআইটির উপর নির্ভরতা রয়েছে।

উইজেটের জন্য একটি ইউনিট পরীক্ষা ব্যর্থ।

কোন শ্রেণিতে সমস্যা আছে?

যদি আপনি "ডিবাগার ফায়ার আপ" বা "কোডটি খুঁজে না পাওয়া পর্যন্ত আমাকে খুঁজে না পাওয়া" বলে উত্তর দিয়ে থাকেন তবে নির্ভরতা নয় কেবল ইউনিট পরীক্ষার গুরুত্ব বুঝতে পারবেন understand

Comments

@ ব্রুক: উইজেটের সমস্ত নির্ভরতার জন্য ফলাফলগুলি কীভাবে দেখছেন? যদি তারা সমস্ত পাস করে তবে অন্যথায় প্রমাণিত হওয়া অবধি উইজেটের সমস্যা।

— dsimcha

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

— asoundmove

@ ডিএসিমচা, আপনি অ-তুচ্ছ নির্ভরশীলতার গ্রাফটিতে না যাওয়া পর্যন্ত এটি যুক্তিযুক্ত বলে মনে হচ্ছে। বলুন যে আপনি একটি জটিল অবজেক্ট পেয়েছেন যার উপর নির্ভরশীলতাগুলির সাথে 3+ স্তর রয়েছে, এটি ও (1) এর পরিবর্তে সমস্যার জন্য একটি (N ^ 2) অনুসন্ধানে পরিণত হয়

— ব্রুক

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

— dsimcha

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

— dsimcha

Answer 4

ভাবুন প্রোগ্রামিং রান্না করার মতো। তারপরে ইউনিট টেস্টিংটি আপনার উপাদানগুলি তাজা, সুস্বাদু ইত্যাদি নিশ্চিত করা সমান as যেখানে ইন্টিগ্রেশন টেস্টটি আপনার খাবারটি সুস্বাদু তা নিশ্চিত করার মতো।

শেষ পর্যন্ত, আপনার খাবারটি সুস্বাদু (বা আপনার সিস্টেমটি কাজ করে) তা নিশ্চিত করা সবচেয়ে গুরুত্বপূর্ণ বিষয়, চূড়ান্ত লক্ষ্য। তবে যদি আপনার উপাদানগুলি, মানে, ইউনিটগুলি, কাজ করে তবে আপনার সন্ধানের জন্য একটি সস্তা উপায় হবে will

প্রকৃতপক্ষে, আপনি যদি আপনার ইউনিট / পদ্ধতিগুলি কাজ করার গ্যারান্টি দিতে পারেন তবে আপনার কার্যকারিতা করার সম্ভাবনা বেশি। আমি "বেশি সম্ভবত" জোর দিয়েছি, "নির্দিষ্ট" এর বিপরীতে। আপনার এখনও আপনার ইন্টিগ্রেশন টেস্টগুলির প্রয়োজন, ঠিক যেমন আপনার এখনও রান্না করা খাবারের স্বাদ গ্রহণের জন্য কারও প্রয়োজন এবং শেষ পণ্যটি ভাল you আপনার তাজা উপাদানের সাথে সেখানে পৌঁছানোর আরও সহজ সময় হবে, এটাই যথেষ্ট।

Comments

এবং যখন আপনার একীকরণ পরীক্ষাগুলি ব্যর্থ হয়, ইউনিট পরীক্ষা সমস্যার শূন্য হতে পারে।

— টিম উইলিসক্রফ্ট

সাদৃশ্য প্রসারিত করার জন্য: আপনি যখন দেখেন যে আপনার খাবারটি ভীষণ স্বাদযুক্ত, তখন এটি আপনার রুটিটি নমনীয় বলে নির্ধারণ করতে কিছুটা তদন্ত করতে পারে। ফলস্বরূপ, ফলাফলটি হ'ল আপনি রান্না করার আগে ছাঁচযুক্ত রুটি পরীক্ষা করার জন্য একটি ইউনিট পরীক্ষা যুক্ত করুন, যাতে সেই বিশেষ সমস্যাটি আর না ঘটে। তারপরে যদি আপনার আর খাবারের ব্যর্থতা হয় তবে আপনি ছাঁচে রুটিটিকে কারণ হিসাবে সরিয়ে দিয়েছেন।

— ক্যারলেসা

এই সাদৃশ্য প্রেম!

— থহলারের

Answer 5

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

বিভিন্ন স্তরের নির্ভরশীলতাগুলির সাথে পরীক্ষার মাধ্যমে আপনাকে নির্দিষ্ট পরিস্থিতিগুলি পরীক্ষা করতে দেয় যা সম্ভবত ইউনিট পরীক্ষায় পরীক্ষা করা হয়নি।

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

সুতরাং সংক্ষেপে, আমি প্রায় সমস্ত আমার প্রকল্পগুলিতে সাধারণত "ইউনিট টেস্টিং" এর তিনটি স্তর ব্যবহার করি:

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

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

Answer 6

এর অন্য দিকটি কী? ইউনিট পরীক্ষাও তার নির্ভরতা পরীক্ষা না করে সত্যই গুরুত্বপূর্ণ? যদি তাই হয় তবে কেন?

ইউনিট। মানে একবচন।

2 টি জিনিস পরীক্ষা করার অর্থ আপনার কাছে দুটি জিনিস এবং সমস্ত কার্যকরী নির্ভরতা।

আপনি যদি কোনও 3 য় জিনিস যুক্ত করেন তবে আপনি পরীক্ষাগুলিতে লিনিয়ার ছাড়িয়ে কার্যকরী নির্ভরতা বাড়িয়ে তোলেন। জিনিসের তুলনায় জিনিসের মধ্যে আন্তঃসংযোগ আরও দ্রুত বৃদ্ধি পায়।

এন আইটেমগুলির মধ্যে এন (এন -1) / 2 সম্ভাব্য নির্ভরশীল সংযোগ রয়েছে tested

এটাই বড় কারণ।

সরলতার মূল্য আছে।

Answer 7

মনে রাখবেন আপনি কীভাবে প্রথম পুনরাবৃত্তি করতে শিখলেন? আমার অধ্যাপক বলেছিলেন "ধরুন আপনার কাছে এমন একটি পদ্ধতি রয়েছে যা এক্স করে" (উদাঃ যে কোনও এক্সের জন্য ফাইবোনাকির সমাধান করে)। "এক্স এর সমাধান করার জন্য আপনাকে সেই পদ্ধতিটি x-1 এবং x-2 এর জন্য কল করতে হবে"। একই শ্রদ্ধায়, নির্ভরশীলতাগুলি কাটিয়ে ওঠার ফলে তারা তাদের বিদ্যমান থাকার ভান করে এবং পরীক্ষা করে যে বর্তমান ইউনিট এটি করা উচিত যা করে। অনুমান অবশ্যই যে আপনি নির্ভরতা হিসাবে কঠোরভাবে পরীক্ষা করা হয়।

এটি মূলত কর্মক্ষেত্রে এসআরপি। এমনকি আপনার পরীক্ষাগুলির জন্য কোনও একক দায়িত্বে মনোনিবেশ করা, আপনাকে কতটা মানসিক জাগ্রত করতে হবে তা সরিয়ে দেয়।

Answer 8

(এটি একটি ছোট্ট উত্তর answer ইঙ্গিতটির জন্য ধন্যবাদ @ টিমউইলিসক্রাফ্ট।)

ত্রুটিগুলি স্থানীয়করণ করা আরও সহজ যদি:

• উভয় ইউনিট-আন্ডার-পরীক্ষা এবং এর প্রতিটি নির্ভরতা স্বতন্ত্রভাবে পরীক্ষা করা হয়।
• প্রতিটি পরীক্ষায় ব্যর্থ হয় যদি এবং কেবল যদি পরীক্ষার দ্বারা আবৃত কোডটিতে কোনও ত্রুটি থাকে।

এটি কাগজে দুর্দান্ত কাজ করে। তবে ওপি-র বর্ণনায় যেমন চিত্রিত হয়েছে (নির্ভরতাগুলি বগি হয়), যদি নির্ভরতাগুলি পরীক্ষা করা না হয় তবে ফল্টের অবস্থানটি চিহ্নিত করা শক্ত be

Comments

নির্ভরতা কেন পরীক্ষা করা হবে না? এগুলি সম্ভবত নিম্ন স্তরের এবং ইউনিট-পরীক্ষার পক্ষে সহজ easier তদুপরি, নির্দিষ্ট কোডটি কভার করার ইউনিট পরীক্ষাগুলির সাহায্যে ত্রুটির অবস্থান নির্ধারণ করা সহজ।

— ডেভিড থর্নলি

Answer 9

অনেক ভাল উত্তর। আমি আরও কয়েকটি পয়েন্ট যুক্ত করব:

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

ইউনিট পরীক্ষার অর্থ হ'ল আপনার ডেভ মেশিনে আপনার সম্পূর্ণ পরিবেশ থাকতে হবে না (যেমন একটি ডাটাবেস, একটি ওয়েব সার্ভার ইত্যাদি)। আমি দৃঢ় বলতে হবে যে, সমস্ত ডেভেলপারদের কি এমন একটি পরিবেশ আছে, তবে কেটে এটা repro বাগ জন্য, ইত্যাদি যাইহোক, যদি কোনো কারণে এটি উৎপাদন পরিবেশ অনুকরণ করা সম্ভব নয় তখন ইউনিট টেস্টিং অন্তত Yu কিছু স্তর দেয় আপনার কোডটি আরও বড় টেস্ট সিস্টেমে যাওয়ার আগে আত্মবিশ্বাসের বিষয়।

Answer 10

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

• স্পষ্টভাবে এর ইন্টারফেসের মাধ্যমে প্রতিটি শ্রেণীর নির্ভরতা নথিভুক্ত করা (দলে যারা নতুন তাদের জন্য খুব সহায়ক)
• ক্লাসগুলি রক্ষণাবেক্ষণে আরও স্পষ্ট এবং সহজ হয়ে উঠছে (একবার আপনি একবার কুৎসিত বস্তু গ্রাফ তৈরির একটি পৃথক শ্রেণিতে রাখবেন)
• আলগা সংযোগ (পরিবর্তনগুলি অনেক সহজ করে তোলা)

Comments

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

— dsimcha

Answer 11

আহ ... এখানে উত্তরগুলিতে ইউনিট এবং ইন্টিগ্রেশন টেস্টের ভাল পয়েন্ট রয়েছে!

আমি এখানে ব্যয় সম্পর্কিত এবং ব্যবহারিক দৃষ্টিভঙ্গি মিস করি । এটি বলেছে যে আমি খুব বিচ্ছিন্ন / পারমাণবিক ইউনিট পরীক্ষার (সম্ভবত একে অপরের থেকে অত্যন্ত স্বতন্ত্র এবং এগুলিকে সমান্তরাল এবং কোনও নির্ভরতা ছাড়াই, যেমন ডাটাবেস, ফাইল সিস্টেম ইত্যাদিতে চালানোর বিকল্পের সাহায্যে) এবং (উচ্চ স্তরের) ইন্টিগ্রেশন পরীক্ষার সুফল দেখতে পাচ্ছি, তবে ... এটি ব্যয় (সময়, অর্থ, ...) এবং ঝুঁকির বিষয় ।

সুতরাং আরও কিছু কারণ রয়েছে, যা আমার অভিজ্ঞতা থেকে "কীভাবে পরীক্ষা করতে হবে" ভাবার আগে আরও অনেক গুরুত্বপূর্ণ (যেমন "কী পরীক্ষা করতে হবে" ) ...

আমার গ্রাহক অতিরিক্ত পরীক্ষার রক্ষণ এবং রক্ষণাবেক্ষণের জন্য অর্থ প্রদান করেন? আমার পরিবেশে কি আরও পরীক্ষামূলক-চালিত পদ্ধতির (পরীক্ষার আগে কোড লিখুন) সত্যই কার্যকর ব্যয় করা যায় (কোড ব্যর্থতার ঝুঁকি / ব্যয় বিশ্লেষণকারী, মানুষ, ডিজাইনের চশমা, পরীক্ষার পরিবেশ সেটআপ)? কোডটি সর্বদা বগি, তবে পরীক্ষার উত্পাদন ব্যবহারের দিকে নিয়ে যাওয়া (সবচেয়ে খারাপ ক্ষেত্রে!) আরও কার্যকর কার্যকর হতে পারে?

এটি আপনার কোডের মান (মানদণ্ড) বা ফ্রেমওয়ার্ক, আইডিই, ডিজাইনের নীতিগুলি ইত্যাদির উপরও নির্ভর করে যা আপনি এবং আপনার দল অনুসরণ করেন এবং তারা কতটা অভিজ্ঞ। একটি ভাল লিখিত, সহজেই বোধগম্য, যথেষ্ট পরিমাণে ডকুমেন্টেড (আদর্শ স্ব-ডকুমেন্টিং), মডুলার, ... কোড বিপরীতে তুলনায় কম কম বাগের পরিচয় দেয়। সুতরাং প্রকৃত "প্রয়োজন", চাপ বা সামগ্রিক রক্ষণাবেক্ষণ / বাগফিক্স ব্যয় / বিস্তৃত পরীক্ষার জন্য ঝুঁকি বেশি নাও হতে পারে।

আসুন আমরা একে একে চূড়ান্ত দিকে নিয়ে যাই যেখানে আমার দলের একজন সহকর্মী পরামর্শ দিয়েছিলেন, আমাদের ডাটাবেসের মধ্যে এবং ক্লাস করে সমস্ত শ্রেণীর জন্য কাঙ্ক্ষিত 100% কভারেজ সহ আমাদের খাঁটি জাভা ইই মডেল লেয়ার কোডটি পরীক্ষা করার চেষ্টা করতে হবে। অথবা যে ব্যবস্থাপকটি ইন্টিগ্রেশন টেস্টগুলি সমস্ত সম্ভাব্য বাস্তব ব্যবহারের ক্ষেত্রে এবং ওয়েব ইউআই ওয়ার্কফ্লোগুলির 100% দিয়ে আচ্ছাদন করতে চায় তা আমরা ব্যর্থ হওয়ার জন্য কোনও ব্যবহারের ক্ষেত্রে ঝুঁকি নিতে চাই না। তবে আমাদের প্রায় 1 মিলিয়ন ইউরোর একটি বাজেট রয়েছে, সমস্ত কিছু কোড করার জন্য বেশ কিছু শক্ত পরিকল্পনা। গ্রাহকের পরিবেশ, যেখানে সম্ভাব্য অ্যাপ্লিকেশন বাগগুলি মানুষ বা সংস্থাগুলির পক্ষে খুব বড় বিপদ হবে না। আমাদের অ্যাপটি অভ্যন্তরীণভাবে কয়েকটি (গুরুত্বপূর্ণ) ইউনিট পরীক্ষা, ইন্টিগ্রেশন টেস্ট, ডিজাইনযুক্ত পরীক্ষার পরিকল্পনাগুলির কী গ্রাহক পরীক্ষা, একটি পরীক্ষার পর্ব ইত্যাদি দিয়ে পরীক্ষা করা হবে আমরা কিছু পারমাণবিক কারখানা বা ফার্মাসিউটিকাল উত্পাদনের জন্য কোনও অ্যাপ বিকাশ করি না!

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

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

সুতরাং আমি বলব এটি সত্যিকারের বিশ্বাস এবং ব্যয় / ঝুঁকি / উপকারের মূল্যায়নের উপর অনেক নির্ভর করে ... বাস্তব জীবনের মতো যেখানে আপনি অনেকগুলি বা 100% সুরক্ষা ব্যবস্থা নিয়ে ঘুরে বেড়াতে চান না এবং চান না।

বাচ্চা কোথাও উপরে উঠতে পারে এবং নীচে পড়ে নিজেই আহত হতে পারে। গাড়ী কাজ বন্ধ করতে পারে কারণ আমি ভুল জ্বালানীতে ভরাট করেছি (অবৈধ ইনপুট :))। টাইম বোতামটি 3 বছর পরে কাজ করা বন্ধ রাখলে টোস্টটি পোড়া হতে পারে। তবে আমি কখনই রাজপথে গাড়ি চালাতে চাই না এবং আমার বিচ্ছিন্ন স্টিয়ারিং হুইলটি আমার হাতে ধরে রাখতে চাই না :)