সংগ্রহস্থল পদ্ধতির পরীক্ষার জন্য কেন আমার ইউনিট পরীক্ষার দরকার?


19

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

ধরা যাক আমি নিম্নলিখিত ইউনিট পরীক্ষাটি তৈরি করেছি:

[TestMethod]
public void GetOrderByIDTest()
{
   //Uses Moq for dependency for getting order to make sure 
   //ID I set up in 'Arrange' is same one returned to test in 'Assertion'
}

সুতরাং যদি আমি সেট আপ করি OrderIdExpected = 5এবং আমার মক অবজেক্ট 5আইডি হিসাবে ফিরে আসে তবে আমার পরীক্ষাটি পাস হবে। আমি এটা পাই. আমার কোডটি কী প্রত্যাশিত বস্তু এবং আইডি প্রত্যাবর্তন করে অন্য কিছু নয়, তা নিশ্চিত করার জন্য আমি একক কোডটি পরীক্ষা করেছি।

আমি যে যুক্তিটি পাব তা হ'ল:

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

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

এই প্রশ্নে যে কোনও সহায়তা প্রশংসিত হয়, ধন্যবাদ!


2
আমি বলি এটি সরাসরি ব্যবহারকারীর পরীক্ষায় প্রেরণ করুন ... তারা যে কোনওভাবে প্রয়োজনীয়তা পরিবর্তন করতে চলেছে ...
নাথান হ্যাফিল্ড

বিষয়গুলি সময়ে সময়ে হালকা রাখার জন্য
কটূক্তি

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

আমি মনে করি আপনি "ইউনিট" পরীক্ষার সংজ্ঞাটি নিয়ে খুব কঠোর হচ্ছেন। ভান্ডার শ্রেণীর জন্য "কাজের একক" কী?
কালেব

এবং নিশ্চিত হয়ে নিন যে আপনি এটি বিবেচনা করছেন: যদি আপনার ইউনিট পরীক্ষাটি আপনি যা যা পরীক্ষা করার চেষ্টা করছেন তার সবটাই যদি মাকে করে দেয় তবে আপনি আসলে কী পরীক্ষা করছেন?
কালেব

উত্তর:


20

ইউনিট পরীক্ষা এবং ইন্টিগ্রেশন পরীক্ষার বিভিন্ন উদ্দেশ্য রয়েছে।

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

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

  1. সামগ্রিকভাবে লিখতে আরও কঠিন হয়ে উঠুন,
  2. প্রয়োজনীয় সমস্ত নির্ভরতাগুলির কারণে এবং আরও নমনীয় হন
  3. কোড কভারেজ কম অফার।

নীচের লাইন: বস্তুর মধ্যে সংযোগগুলি সঠিকভাবে কাজ করছে কিনা তা যাচাই করতে ইন্টিগ্রেশন টেস্টিং ব্যবহার করুন তবে কার্যকরী প্রয়োজনীয়তা যাচাই করতে প্রথমে ইউনিট পরীক্ষার উপর ঝুঁকুন ।


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


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

1
যদি এসপি ডাটাবেস থেকে সবেমাত্র ফলাফল ফিরিয়ে দেয় তবে একটি ইন্টিগ্রেশন পরীক্ষা পর্যাপ্ত হতে পারে। এটিতে যদি তুচ্ছ তর্ক থাকে তবে ইউনিট পরীক্ষাগুলি নির্দেশিত হয়। এছাড়াও স্ট্যাকওভারফ্লো / প্রশ্নগুলি / ১১১২14১14৪৪/২ এবং এমএসডিএন.মিক মাইক্রোসফট /en-us/library/aa833169(v=vs.100).aspx (এসকিউএল সার্ভার নির্দিষ্ট) দেখুন।
রবার্ট হার্ভে

12

আমি বাস্তববাদীদের পক্ষে আছি। আপনার কোডটি দুটিবার পরীক্ষা করবেন না।

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

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

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

1
@ মার্সেল, আমি এটিতে চলে এসেছি। আমি কখনও কখনও সত্যিকারের ডাটাবেসের বিরুদ্ধে আমার সমস্ত পরীক্ষা চালিয়ে সমাধান করেছি।
উইনস্টন ইওয়ার্ট

4

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

অতিরিক্ত হিসাবে, ইউনিট পরীক্ষাসহ নিম্নোক্ত সুবিধা রয়েছে:

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

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


4

টেস্টগুলি যখন সেগুলি ভেঙে যায় তখন কার্যকর: সক্রিয় বা পুনরায় সক্রিয়ভাবে-

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

বিবেচনাধীন সিস্টেমটি যদি গণনার যুক্তির চেয়ে ডেটার উপরে / কাছাকাছি নির্ভর করে তবে ইন্টিগ্রেশন টেস্টগুলিকে আরও বেশি গুরুত্ব দেওয়া উচিত।

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

সংগ্রহস্থল প্যাটার্নের গণ্য বা ব্যবসায়িক যুক্তি থাকা উচিত নয়। এটি ডাটাবেসের খুব কাছে। তবে সংগ্রহস্থলটি ব্যবসায়িক যুক্তির সাথেও এটি ব্যবহার করে। সুতরাং এটি একটি ব্যালেন্সকে আঘাত করার প্রশ্ন।

ইউনিট টেস্টগুলি সংগ্রহস্থল কীভাবে আচরণ করে তা পরীক্ষা করতে পারে। ইন্টিগ্রেশন টেস্টগুলি সংগ্রহস্থলটি যখন ডাকা হত তখন সত্যিই যা ঘটেছিল তা পরীক্ষা করতে পারে।

এখন, "সত্যিই কী ঘটেছে" মনে হচ্ছে এটি খুব মোহনীয় বলে মনে হচ্ছে। ধারাবাহিকভাবে এবং বারবার চলার জন্য এটি খুব ব্যয়বহুল হতে পারে। ভঙ্গুর পরীক্ষার ক্লাসিক সংজ্ঞা এখানে প্রযোজ্য।

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


আমি এটি পছন্দ করি: "এখন,"
এটকনওয়ে

2

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

সুতরাং (এটি একটি খুব সরল উদাহরণ):

interface IOrderRepository
{
    Order GetOrderByID(Guid id);
}

class OrderRepository : IOrderRepository
{
    private readonly ISqlExecutor sqlExecutor;
    public OrderRepository(ISqlExecutor sqlExecutor)
    {
        this.sqlExecutor = sqlExecutor;
    }

    public Order GetOrderByID(Guid id)
    {
        var sql = "SELECT blah, blah FROM Order WHERE OrderId = @p0";
        var dataset = this.sqlExecutor.Execute(sql, p0 = id);
        var result = this.orderFromDataset(dataset);
        return result;
    }
}

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

আপনাকে এখনও আপনার সঞ্চিত পদ্ধতিগুলি পরীক্ষা করতে হবে।


0

আমি এটিকে খুব সাধারণ চিন্তার রেখাতে হ্রাস করতে পারি: ফেভারিট ইউনিট পরীক্ষা কারণ এটি বাগগুলি সনাক্ত করতে সহায়তা করে। এবং এটি ধারাবাহিকভাবে করুন কারণ অসঙ্গতিগুলি বিভ্রান্তির সৃষ্টি করে।

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.