(ডাটাবেস) ইন্টিগ্রেশন পরীক্ষা খারাপ?


120

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

আমি দেখতে পেয়েছি, কিছু ক্ষেত্রে, একটি ইউনিট-পরীক্ষা কেবল কিছুই প্রমাণ করে না।

উদাহরণস্বরূপ নিম্নলিখিত (তুচ্ছ, নিষ্পাপ) সংগ্রহস্থল বাস্তবায়ন (পিএইচপি-তে) নেওয়া যাক:

class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}

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

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

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

অন্য কথায়, আমি একটি পরীক্ষা করে তোলে উত্পন্ন QUERY সম্বন্ধে গবেষকেরা, মান ছাড়া মূলত, কারণ এটি পরীক্ষার কীভাবে মত মনে findByKeyword()পদ্ধতি ছিল বাস্তবায়িত , কিন্তু যে প্রমাণ নয় যে এটা আসলে কাজ করে

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

আপনি এই জাতীয় পরিস্থিতিতে কীভাবে মোকাবিলা করবেন?

ইন্টিগ্রেশন টেস্টগুলি কি এই জাতীয় ক্ষেত্রে সত্যই "খারাপ"?

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


5
Agitar.com/downloads/WWOOfTestivus.pdf পড়ুন , বিশেষত পৃষ্ঠা 6 "ইউনিটের চেয়ে পরীক্ষাটি আরও গুরুত্বপূর্ণ"।
ডক ব্রাউন 21

2
@ user61852 এটি বর্ণনায় "নিষ্পাপ" বলে, হ্যাঁ?
mindplay.dk

4
আপনার সহকর্মী কীভাবে একেবারে নিশ্চিত হবেন যে তার উপহাস করা ডেটাবেসটি আসল জিনিস হিসাবে আচরণ করে?
থোরবজর্ন রাভন অ্যান্ডারসন

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

3
@ মাইন্ডপ্লে.ডকে: এই অনুচ্ছেদে মূল বাক্যটি হ'ল "তবে কোনও ডগমাতে আটকে যাবেন না the যে পরীক্ষাটি লেখার দরকার তা লিখুন” " আপনার সহকর্মী মনে হচ্ছে কোনও মতবাদে আটকে আছে And এবং আপনাকে কারও দরকার নেই do পরীক্ষাটি কী তা আপনার উদাহরণে লিখতে হবে তা ব্যাখ্যা করে - আপনি এটি ইতিমধ্যে জানেন testing আপনার ডাটাবেসটি কোয়েরিটি বোঝার জন্য পরীক্ষার জন্য আপনাকে সত্যিকারের ডাটাবেসের বিরুদ্ধে ক্যোয়ারী চালাতে হবে - কোনও বিদ্রূপ আপনাকে বলতে পারে না এটি।
ডক ব্রাউন

উত্তর:


129

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

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

        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)

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

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


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


13
"1 এর পরীক্ষার জন্য যা এর বাস্তবায়নের একটি নিখুঁত দর্পণ তা আসলে কোনও কিছুরই পরীক্ষা করে না" " সব খুব সাধারণ। আমি এটাকে ডপপেলাগঞ্জার অ্যান্টিপ্যাটার্ন বলি
dodgethesteamroller

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

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

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

1
ইন্টিগ্রেশন টেস্টের ইউনিটেটের অনুক্রম এবং অনুপাত সম্পর্কে অত্যন্ত প্রস্তাবিত উপস্থাপনা: vimeo.com/80533536 খুব ভালভাবে ব্যাখ্যা করা হয়েছে।
szalski

88

আমার একজন সহকর্মী বজায় রাখছেন যে ইন্টিগ্রেশন টেস্টগুলি হ'ল সব ধরণের খারাপ এবং ভুল - সবকিছুই একক-পরীক্ষিত হতে হবে,

এটি অ্যান্টিবায়োটিকগুলি খারাপ বলে কিছুটা বলার মতো - ভিটামিন দিয়ে সবকিছু নিরাময় করা উচিত।

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

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

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

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


আপনি কি পরীক্ষা করছেন না যে ডাটাবেসে নির্দিষ্ট ডেটা রয়েছে কিনা?
তুলিনাস কর্ডোভা

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

হ্যাঁ - আমি উদাহরণ হিসাবে যেমনটি উল্লেখ করেছি, তা তুচ্ছ; একটি বাস্তব সংগ্রহস্থলের একটি ক্যোয়ারী রচয়িতা, ইত্যাদি ব্যবহার জটিল অনুসন্ধান এবং বাছাই অপশন, যেমন সর্বপ্রকার হতে পারে
mindplay.dk

2
উত্তম উত্তর, তবে আমি যুক্ত করব যে ইউনিট পরীক্ষা দ্রুত হয় তা নিশ্চিত করার জন্য ডিবি স্মৃতিতে থাকা উচিত।
BЈовић

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

17

ইউনিট পরীক্ষা সমস্ত ত্রুটি ধরা দেয় না। তবে সেগুলি সেট আপ করার তুলনায় সস্তা এবং (অন্যান্য) পরীক্ষা অন্যান্য ধরণের পরীক্ষার তুলনায় run ইউনিট পরীক্ষাগুলি মাঝারি মানের এবং নিম্ন-মধ্যমিত ব্যয়ের সংমিশ্রণ দ্বারা ন্যায্য।

এখানে বিভিন্ন ধরণের পরীক্ষার জন্য ত্রুটি সনাক্তকরণের হার দেখানো একটি টেবিল রয়েছে।

এখানে চিত্র বর্ণনা লিখুন

উত্স: ম্যাককনেল কর্তৃক কোড 2 সম্পূর্ণ in


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

3
@ রবারডাক এই চার্টটি ২০০ 2006 সালের একটি বইয়ের এবং এটি 1986, 1996, 2002-এর তথ্যের উপর ভিত্তি করে (যদি আপনি মনোযোগ দিয়ে দেখুন)। উত্সগুলিতে ডেটা সংগ্রহের প্রোটোকলগুলিতে আমি নজর রাখিনি, তারা কখনই কোনও ত্রুটিটি সনাক্ত করতে শুরু করেছিল এবং এটি কীভাবে রিপোর্ট করা হয়েছিল তা আমি বলতে পারি না। এই চার্ট কি কিছুটা পুরানো হতে পারে? এটা পারে। গত ডিসেম্বরে আমি একটি সেমিনারে ছিলাম এবং প্রশিক্ষক উল্লেখ করেছিলেন যে ইন্টিগ্রেশন পরীক্ষাগুলি ইউনিট পরীক্ষার চেয়ে বেশি বাগ খুঁজে পায় (২, আইর্কের একটি উপাদান দ্বারা)। এই চার্টটি বলে যে তারা প্রায় একই রকম।
নিক আলেক্সেভ

13

না, তারা খারাপ নয়। আশা করি, একের ইউনিট এবং ইন্টিগ্রেশন পরীক্ষা করা উচিত। এগুলি উন্নয়ন চক্রের বিভিন্ন পর্যায়ে ব্যবহৃত হয় এবং চালিত হয়।

ইউনিট টেস্ট

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

সুতরাং, একটি ডাটাবেসের জন্য, এর মতো কিছু হওয়া উচিত:

IRespository

List<Product> GetProducts<String Size, String Color);

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

ইন্টিগ্রেশন টেস্ট

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

  • পরিবেশ স্বাস্থ্য স্থায়িত্ব প্রস্তুতি
  • আসল জিনিস পরীক্ষা করা হচ্ছে

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

ইন্টিগ্রেশন টেস্টগুলি পরিবেশকে বৈধতা দেওয়ার জন্য এবং আসল জিনিসটি কার্যকর কিনা তা নিশ্চিত করার পক্ষে যথেষ্ট মূল্যবান হতে পারে।

একটি উভয় থাকা উচিত।

  • প্রতিটি বিল্ডের জন্য ইউনিট পরীক্ষা চালান।
  • প্রতিটি স্থাপনার জন্য ইন্টিগ্রেশন পরীক্ষা চালান।

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

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

11

ডাটাবেস ইন্টিগ্রেশন টেস্টগুলি খারাপ নয়। আরও বেশি, তারা প্রয়োজনীয়।

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

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

উপসংহার

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


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

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

@ ডেভিড আপনার সিআই / সিডি লাইনে কোনও ডাটাবেস আছে? অবশ্যই, এটি বেশ আদর্শ বৈশিষ্ট্য । বিটিডাব্লু, আমি ইউনিট পরীক্ষার পরিবর্তে ইন্টিগ্রেশন টেস্টের পক্ষে পরামর্শ দিচ্ছি না - আমি ইউনিট পরীক্ষার সাথে একত্রে ইন্টিগ্রেশন টেস্টের পক্ষে করছি । দ্রুত ইউনিট পরীক্ষা অপরিহার্য, তবে উপহাসকৃত ইন্টারঅ্যাকশনগুলির সাথে ইউনিট পরীক্ষার উপর নির্ভর করতে ডাটাবেসগুলি খুব জটিল।
el.pescado

@ el.pescado আমাকে একমত হতে হবে না। আপনার ডাটাবেস যোগাযোগ যদি বিমূর্ততার একটি স্তরের পিছনে থাকে, তবে এটি উপহাস করা সত্যিই সহজ। আপনি ঠিক করতে পারেন কোন বস্তুটি ফিরে আসবে। এছাড়াও, যে কোনও কিছু স্ট্যান্ডার্ড হ'ল এটিকে একটি ভাল জিনিস করে না।
ডেভিড

@ ডেভিড আমি মনে করি এটি নির্ভর করে আপনি কীভাবে ডাটাবেসের কাছে যান approach এটি বাস্তবায়নের বিশদ বা সিস্টেমের গুরুত্বপূর্ণ অংশ ? (আমি আধুনিক দিকে চর্বিহীন) । আপনি যদি ডেটাবেসটিকে ডেটা বোবা স্টোরেজ হিসাবে বিবেচনা করেন, তবে হ্যাঁ, আপনি ইন্টিগ্রেশন পরীক্ষা ছাড়াই এটি করতে পারেন। তবে, যদি ডাটাবেসে কোনও যুক্তি থাকে - সীমাবদ্ধতা, ট্রিগার, বিদেশী কী, লেনদেন, বা আপনার ডেটা স্তর সরল ORM পদ্ধতির পরিবর্তে কাস্টম এসকিউএল ব্যবহার করে তবে আমি অনুভব করি যে একক পরীক্ষাগুলিই যথেষ্ট হবে না।
el.pescado

6

আপনার দুজনেরই দরকার।

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

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


6

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

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

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

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

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

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

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

আরেকটি বিষয় বিবেচনা করার বিষয় হ'ল আপনার অ্যাপ্লিকেশনটির ডেটাবেসগুলির সাথে নির্ভরতার মাত্রা।

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

"আজ অনেক অ্যাপ্লিকেশন তাদের ডেটাবেস সার্ভারটি নিচে চলে গেলে কেবল এগুলি কাজ করে না" - এটি সত্যই গুরুত্বপূর্ণ পয়েন্ট!
el.pescado

জটিল উপহাসের সীমা সম্পর্কে ভাল ব্যাখ্যা যেমন এসকিউএলকে বিদ্রূপ করার জন্য অন্য ভাষা ব্যবহার করা। যখন পরীক্ষার কোডটি এত জটিল হয়ে যায় যে মনে হয় এটি নিজেই পরীক্ষা করা দরকার, এটি একটি QA গন্ধ।
ডডজেথেসট্রোলার

1

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

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

তবে বিদ্রূপ করার জন্য প্রায়শই ভুলে যাওয়া এবং কিছুটা ব্যয়বহুল বিকল্প / সঙ্গী হ'ল "ভার্চুয়ালাইজেশন"

আপনি কি একটি একক ক্রিয়াকলাপটি পরীক্ষা করার জন্য অস্থায়ী, স্মৃতিশক্তিযুক্ত তবে "সত্য" ডিবি উদাহরণটি স্পিন করতে পারবেন? হ্যাঁ ? সেখানে, আপনার আরও ভাল পরীক্ষা রয়েছে, যা প্রকৃত ডেটা সংরক্ষণ এবং পুনরুদ্ধার করে check

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


1
এই নিছক তৈরি এবং ব্যাখ্যা পয়েন্ট পুনরাবৃত্তি বলে মনে হয় এই পূর্বে উত্তর যে বেশ কয়েক ঘন্টা আগে পোস্ট করা হয়েছে
মশা

0

Unit Testsএবং Integration Testsহয় orthgonal একে অপরের সাথে। আপনি যে অ্যাপ্লিকেশনটি তৈরি করছেন তাতে তারা আলাদা দৃষ্টিভঙ্গি দেয়। সাধারণত আপনি উভয় চান । তবে সময়ের বিন্দুটি আলাদা হয়, যখন আপনি কোন ধরণের পরীক্ষা চান।

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

অন্যদিকে, এমন কিছু জিনিস রয়েছে যা কেবলমাত্র ডেটাবেস ছাড়াই কঠোর পরিস্থিতিতে একক পরীক্ষা করা যায়। সম্ভবত আপনার কোডে রেসের শর্ত রয়েছে এবং একটি ডিবি-এর কাছে কল একটি লঙ্ঘন ছুড়ে দেয় unique constraintযা কেবলমাত্র যদি আপনি প্রকৃতপক্ষে আপনার সিস্টেমটি ব্যবহার করেন তবে নিক্ষেপ করা যেতে পারে। তবে এই ধরণের পরীক্ষাগুলি ব্যয়বহুল আপনি এগুলি প্রায়শই চালাতে পারবেন না (এবং চান না) unit tests


0

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

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

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

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

https://cucumber.io/

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

স্ট্যাক ওভারফ্লো অনুসারে, বাস্তব বিষয়গুলি ইউনিট পরীক্ষায় অন্তর্ভুক্ত করার জন্য অবাস্তব হলে মশকরা ব্যবহৃত হয়।

https://stackoverflow.com/questions/2665812/what-is-mocking

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

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

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

স্ট্যাক এক্সচেঞ্জের একজন সহ-প্রতিষ্ঠাতা 100% ইউনিট পরীক্ষার কভারেজ দেওয়ার সুবিধা সম্পর্কে নিশ্চিত নন। আমিও নই। আমি আরও একটি সম্পূর্ণ "ইন্টিগ্রেশন টেস্ট" নেব যা কোনও দিন ডাটাবেস বিদ্রূপগুলি বজায় রাখার জন্য ডাটাবেসকে হিট করে।

https://www.joelonsoftware.com/2009/01/31/from-podcast-38/


এটা এত সুস্পষ্ট যে আপনি ইউনিট এবং ইন্টিগ্রেশন পরীক্ষার মধ্যে পার্থক্য বুঝতে পারছি না
BЈовић

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

-1

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

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


"আপনি তাদের নিয়ন্ত্রণ করতে পারবেন না এর জন্য +1 " (তারা সংহতকরণ পরীক্ষার পর্যায়ে যেতে পারে তবে উত্পাদনে ব্যর্থ হতে পারে) "
তুলিনাস কর্ডোভা

আপনি এগুলি সন্তোষজনক ডিগ্রীতে নিয়ন্ত্রণ করতে পারেন
el.pescado

আমি আপনার বক্তব্যটি পেয়েছি, তবে আমি মনে করি এটি আজকের চেয়ে সত্যই ব্যবহৃত হত? অটোমেশন এবং সরঞ্জামগুলির সাথে (ডকারের মতো) আপনি ইন্টিগ্রেশন টেস্ট-স্যুটগুলির জন্য আপনার সমস্ত বাইনারি / সার্ভার নির্ভরতা সঠিকভাবে এবং নির্ভরযোগ্যতার সেটআপটিকে পুনরায় তৈরি করতে এবং পুনরাবৃত্তি করতে পারেন। অবশ্যই, হ্যাঁ, শারীরিক হার্ডওয়্যার (এবং তৃতীয় পক্ষের পরিষেবাগুলি ইত্যাদি) ব্যর্থ হতে পারে।
mindplay.dk

5
আমি একেবারে একমত না। আপনার (অতিরিক্ত) ইন্টিগ্রেশন পরীক্ষাগুলি লিখতে হবে কারণ এক্সটেনাল নির্ভরতা ব্যর্থ হতে পারে। বাহ্যিক নির্ভরতার নিজস্ব কৌতুহল থাকতে পারে, যা আপনি সম্ভবত সমস্ত কিছু উপহাস করার সময় মিস করবেন।
পল কার্টেসার

1
@ পোলক এখনও কোন উত্তরকে স্বীকৃত হিসাবে চিহ্নিত করবেন তা নিয়ে চিন্তাভাবনা করছেন তবে আমি একই সিদ্ধান্তে ঝুঁকছি।
mindplay.dk
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.