স্বয়ংক্রিয় পরীক্ষার প্রকারভেদ

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

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

সাধারণ ধরনের পরীক্ষা

ইউনিট পরীক্ষা

ইউনিট পরীক্ষার সুযোগ সবচেয়ে ছোট। এগুলি প্রায় গাণিতিক উপায়ে কোডের ছোট অংশ, বা সম্পূর্ণরূপে স্টেটলেস কোড পরীক্ষা করার জন্য ব্যবহার করা হয়: যদি আমি আপনার কোড X, Y, এবং Z ইনপুট দিয়ে দিই, তাহলে এর আউটপুট A, B এবং C হওয়া উচিত।

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

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

উপাদান পরীক্ষা

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

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

ইন্টিগ্রেশন পরীক্ষা

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

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

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

ধোঁয়া পরীক্ষা

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

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

স্মোক টেস্টগুলি একটি বড় কোডবেসে আপনার package.json-এর test স্ক্রিপ্টের অধীনে চালানোর জন্য একটি ভাল প্রার্থী হতে পারে। ম্যানুয়াল টেস্টিং এক ধরণের ধোঁয়া পরীক্ষা হিসাবেও কাজ করতে পারে।

রিগ্রেশন পরীক্ষা

রিগ্রেশন টেস্টিং হল এক ধরনের ধোঁয়া পরীক্ষা যা নিশ্চিত করে যে বিদ্যমান বৈশিষ্ট্যগুলি কাজ চালিয়ে যাচ্ছে, বা নতুন রিলিজ বা অন্যান্য বৈশিষ্ট্য বিকাশের পরে পুরানো বাগগুলি পুনরায় চালু করা হবে না।

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

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

ভিজ্যুয়াল পরীক্ষা

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

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

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

শেষ থেকে শেষ পরীক্ষা

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

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

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

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

API পরীক্ষা

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

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

অন্যান্য প্রকার

আপনার উত্সের উপর নির্ভর করে, পরীক্ষার জন্য আরও বিভিন্ন পদ্ধতি রয়েছে যা কার্যকর হতে পারে। আকর্ষণীয় উদাহরণ নিম্নলিখিত অন্তর্ভুক্ত:

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

কোড কভারেজ

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

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

সম্পদ

• চারটি সাধারণ ধরনের কোড কভারেজ

আপনার উপলব্ধি পরীক্ষা করুন