স্বয়ংক্রিয় পরীক্ষাগুলি সাধারণত ম্যানুয়ালি একটি স্ক্রিপ্ট চালানোর মাধ্যমে চালানো যেতে পারে, বা পরীক্ষার কাঠামোর সাহায্যকারী ব্যবহার করে, যাকে প্রায়শই একটি টেস্ট রানার বলা হয়, পরীক্ষাগুলি খুঁজে পেতে এবং চালানোর জন্য। যদিও আপনি সবসময় আপনার স্ক্রিপ্ট ম্যানুয়ালি চালাতে চান না। আপনার পরীক্ষা চালানোর অনেক উপায় রয়েছে যা বিকাশের জীবনচক্র চলাকালীন বিভিন্ন পয়েন্টে প্রতিক্রিয়া এবং আত্মবিশ্বাস প্রদান করতে পারে।
পূর্বশর্ত স্ক্রিপ্ট
ওয়েব প্রজেক্টে সাধারণত একটি কনফিগারেশন ফাইল থাকে—তাদের package.json ফাইল—যা npm, pnpm, Bun বা অনুরূপ দ্বারা সেট আপ করা হয়। এই কনফিগারেশন ফাইলটিতে আপনার প্রকল্পের নির্ভরতা এবং অন্যান্য তথ্য, সেইসাথে সাহায্যকারী স্ক্রিপ্ট রয়েছে। এই সহায়ক স্ক্রিপ্টগুলি কীভাবে আপনার প্রকল্প তৈরি, চালাতে বা পরীক্ষা করতে হয় তা অন্তর্ভুক্ত করতে পারে।
package.json এর ভিতরে, আপনাকে test নামে একটি স্ক্রিপ্ট যোগ করতে হবে যা আপনার পরীক্ষাগুলি কীভাবে চালাতে হয় তা বর্ণনা করে। এটি গুরুত্বপূর্ণ কারণ, যখন npm বা অনুরূপ টুল ব্যবহার করা হয়, তখন "পরীক্ষা" স্ক্রিপ্টের বিশেষ অর্থ থাকে । এই স্ক্রিপ্টটি শুধুমাত্র একটি একক ফাইলের দিকে নির্দেশ করতে পারে যা একটি ব্যতিক্রম ছুঁড়ে দেয় node tests.js এর মতো কিছু - তবে আমরা একটি প্রতিষ্ঠিত পরীক্ষা রানারকে নির্দেশ করতে এটি ব্যবহার করার পরামর্শ দিই।
আপনি যদি আপনার টেস্ট রানার হিসাবে Vitest ব্যবহার করেন, তাহলে আপনার package.json ফাইলটি নিচের মত দেখাবে:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
এই ফাইলের সাথে npm test চালানো হলে একবার Vitest-এর ডিফল্ট পরীক্ষা চালানো হয়। Vitest-এ, ডিফল্ট হল ".test.js" বা অনুরূপ শেষ হওয়া সমস্ত ফাইল খুঁজে বের করা এবং সেগুলি চালানো। আপনার নির্বাচিত পরীক্ষা রানার উপর নির্ভর করে, কমান্ড সামান্য ভিন্ন হতে পারে.
আমরা এই কোর্স জুড়ে উদাহরণের জন্য Vitest, একটি ক্রমবর্ধমান জনপ্রিয় পরীক্ষার কাঠামো ব্যবহার করা বেছে নিয়েছি। আপনি এই সিদ্ধান্ত সম্পর্কে আরও পড়তে পারেন ভিটেস্টে একজন টেস্ট রানার হিসাবে । যাইহোক, এটা মনে রাখা গুরুত্বপূর্ণ যে টেস্ট ফ্রেমওয়ার্ক এবং রানার্স-এমনকি ভাষা জুড়ে-একটি সাধারণ আঞ্চলিক ভাষা থাকে।
ম্যানুয়াল পরীক্ষা আহ্বান
আপনি কোডবেসে সক্রিয়ভাবে কাজ করার সময় ম্যানুয়ালি আপনার স্বয়ংক্রিয় পরীক্ষাগুলিকে ট্রিগার করা (যেমন পূর্বের উদাহরণে npm test ব্যবহার করা) ব্যবহারিক হতে পারে। সেই বৈশিষ্ট্যটি বিকাশ করার সময় একটি বৈশিষ্ট্যের জন্য পরীক্ষাগুলি লিখলে আপনাকে বৈশিষ্ট্যটি কীভাবে কাজ করা উচিত তা বোঝাতে সহায়তা করতে পারে — এটি পরীক্ষা-চালিত বিকাশের (TDD) ধারণাটিকে স্পর্শ করে৷
টেস্ট রানারদের সাধারণত একটি সংক্ষিপ্ত কমান্ড থাকে যা আপনি আপনার কিছু বা সমস্ত পরীক্ষা চালানোর জন্য আহ্বান করতে পারেন এবং সম্ভবত একটি প্রহরী মোড যা আপনি সেভ করার সাথে সাথে পরীক্ষাগুলি পুনরায় চালায়। একটি নতুন বৈশিষ্ট্য বিকাশ করার সময় এগুলি সমস্ত সহায়ক বিকল্প, এবং এগুলি দ্রুত প্রতিক্রিয়া সহ একটি নতুন বৈশিষ্ট্য, এর পরীক্ষা বা উভয়ই লেখা সহজ করার জন্য ডিজাইন করা হয়েছে৷ Vitest, উদাহরণস্বরূপ, ডিফল্টরূপে প্রহরী মোডে কাজ করে: vitest কমান্ড পরিবর্তনগুলি দেখবে এবং এটি খুঁজে পাওয়া যেকোনো পরীক্ষা পুনরায় চালাবে। আপনি পরীক্ষা লেখার সময় আমরা এটিকে অন্য উইন্ডোতে খোলা রাখার পরামর্শ দিই, যাতে আপনি আপনার পরীক্ষাগুলি তৈরি করার সাথে সাথে দ্রুত প্রতিক্রিয়া পেতে পারেন।
কিছু রানার আপনাকে only আপনার কোড হিসাবে পরীক্ষা চিহ্নিত করার অনুমতি দেয়। যদি আপনার কোডে only পরীক্ষা অন্তর্ভুক্ত থাকে, তবে আপনি যখন পরীক্ষা চালাবেন তখন শুধুমাত্র এই পরীক্ষাগুলিই ট্রিগার করবে, যাতে পরীক্ষার বিকাশ দ্রুত এবং সমস্যা সমাধান করা সহজ হয়। এমনকি আপনার সমস্ত পরীক্ষা দ্রুত সম্পন্ন হলেও, only ব্যবহার করলে আপনার ওভারহেড কমাতে পারে এবং আপনি যে বৈশিষ্ট্য বা পরীক্ষায় কাজ করছেন তার সাথে সম্পর্কহীন পরীক্ষা চালানোর বিভ্রান্তি দূর করতে পারে।
ছোট প্রকল্পগুলির জন্য, বিশেষত শুধুমাত্র একজন বিকাশকারীর সাথে প্রকল্পগুলির জন্য, আপনি নিয়মিত আপনার কোডবেসের সম্পূর্ণ পরীক্ষা স্যুট চালানোর অভ্যাস গড়ে তুলতে চাইতে পারেন। এটি বিশেষত সহায়ক যদি আপনার পরীক্ষাগুলি ছোট হয় এবং দ্রুত সম্পন্ন হয় (আপনার সমস্ত পরীক্ষার জন্য কয়েক সেকেন্ডের বেশি নয়) যাতে আপনি এগিয়ে যাওয়ার আগে সবকিছু কাজ করছে তা নিশ্চিত করতে পারেন।
প্রি-সাবমিট বা পর্যালোচনার অংশ হিসেবে পরীক্ষা চালান
অনেক প্রকল্প নিশ্চিত করতে বেছে নেয় যে কোডবেস সঠিকভাবে কাজ করছে যখন কোডটি তার main শাখায় আবার মার্জ করা হবে। আপনি যদি পরীক্ষায় নতুন হন, কিন্তু অতীতে ওপেন সোর্স প্রজেক্টে অবদান রেখে থাকেন, তাহলে আপনি সম্ভবত পুল রিকোয়েস্ট (PR) প্রক্রিয়ার একটি অংশ লক্ষ্য করেছেন যে প্রজেক্টের সমস্ত পরীক্ষা পাস হয়েছে, অর্থাৎ আপনার উত্তেজনাপূর্ণ নতুন অবদান নেই বিদ্যমান প্রকল্পকে নেতিবাচকভাবে প্রভাবিত করে।
আপনি যদি স্থানীয়ভাবে আপনার পরীক্ষাগুলি চালান, আপনার প্রকল্পের অনলাইন সংগ্রহস্থল (উদাহরণস্বরূপ, GitHub বা অন্য কোড হোস্টিং পরিষেবা) জানবে না যে আপনার পরীক্ষাগুলি পাস হচ্ছে, তাই প্রি-সাবমিট টাস্ক হিসাবে পরীক্ষা চালানো সমস্ত অবদানকারীদের কাছে স্পষ্ট করে দেয় যে সবকিছু কাজ করছে৷
GitHub, উদাহরণস্বরূপ, এগুলিকে "স্ট্যাটাস চেক" হিসাবে উল্লেখ করে যা আপনি GitHub অ্যাকশনের মাধ্যমে যোগ করতে পারেন। গিটহাব অ্যাকশনগুলি মূলত এক ধরণের পরীক্ষা: অ্যাকশনটি পাস করার জন্য প্রতিটি পদক্ষেপ অবশ্যই সফল হতে হবে (ব্যর্থ হবেন না বা একটি Error নিক্ষেপ করবেন না)। আপনি একটি প্রকল্পের জন্য সমস্ত PR-এ অ্যাকশন প্রয়োগ করতে পারেন, এবং একটি প্রোজেক্টের জন্য আপনার কোড অবদানের আগে অ্যাকশন পাস করতে হবে। GitHub-এর ডিফল্ট Node.js অ্যাকশন npm test চালায় এটির একটি ধাপ হিসেবে।
আপনার কোডবেস সর্বদা "সবুজ" হয় তা নিশ্চিত করার জন্য পরীক্ষা করার এই পদ্ধতিটি এমন কোড গ্রহণ না করে যা সফলভাবে পরীক্ষা চালায় না।
ক্রমাগত একীকরণের অংশ হিসাবে পরীক্ষা চালান
একবার আপনার সবুজ পিআর গৃহীত হলে, বেশিরভাগ কোডবেস আপনার প্রকল্পের main শাখার উপর ভিত্তি করে পরীক্ষা চালায় , আগের পিআরের পরিবর্তে। এটি অবিলম্বে ঘটতে পারে, বা নিয়মিতভাবে (উদাহরণস্বরূপ, প্রতি ঘণ্টায় বা রাতে)। এই ফলাফলগুলি প্রায়শই একটি অবিচ্ছিন্ন ইন্টিগ্রেশন (CI) ড্যাশবোর্ডের অংশ হিসাবে দেখানো হয় যা সামগ্রিক প্রকল্পের স্বাস্থ্য দেখায়।
এই CI পদক্ষেপটি অপ্রয়োজনীয় বলে মনে হতে পারে, বিশেষ করে ছোট কোডবেস সহ প্রকল্পগুলির জন্য- পর্যালোচনার সময় পরীক্ষাগুলি পাস করা হয়, তাই পরিবর্তনের পরে তাদের পাস করা উচিত। যাইহোক, এটি সর্বদা সত্য নয়! সফলভাবে সবুজ ফলাফল তৈরি করার পরেও আপনার পরীক্ষাগুলি হঠাৎ ব্যর্থ হতে পারে। এর কিছু কারণ অন্তর্ভুক্ত:
- বেশ কয়েকটি পরিবর্তন "একযোগে" গৃহীত হয়েছিল, কখনও কখনও একটি জাতি শর্ত হিসাবে পরিচিত, এবং তারা সূক্ষ্ম, অপরীক্ষিত উপায়ে একে অপরকে প্রভাবিত করে।
- আপনার পরীক্ষাগুলি পুনরুত্পাদনযোগ্য নয়, বা তারা "ফ্ল্যাকি" কোড পরীক্ষা করে—কোন কোড পরিবর্তন ছাড়াই তারা পাস এবং ব্যর্থ উভয়ই হতে পারে।
- আপনি যদি আপনার কোডবেসের বাইরের সিস্টেমগুলির উপর নির্ভর করেন তবে এটি ঘটতে পারে। একটি প্রক্সির জন্য,
Math.random() > 0.05হলে পরীক্ষার কল্পনা করুন —এটি এলোমেলোভাবে 5% সময় ব্যর্থ হবে।
- আপনি যদি আপনার কোডবেসের বাইরের সিস্টেমগুলির উপর নির্ভর করেন তবে এটি ঘটতে পারে। একটি প্রক্সির জন্য,
- কিছু পরীক্ষা প্রতিটি পিআর-এ চালানোর জন্য খুব ব্যয়বহুল বা ব্যয়বহুল, যেমন শেষ থেকে শেষ পরীক্ষা (এটি স্বয়ংক্রিয় পরীক্ষার প্রকারের মধ্যে আরও বেশি), এবং তারা সবসময় সতর্ক না করেই সময়ের সাথে ভেঙে যেতে পারে।
এই সমস্যাগুলির কোনওটিই কাটিয়ে ওঠা অসম্ভব নয়, তবে এটি উপলব্ধি করা মূল্যবান যে সাধারণভাবে পরীক্ষা এবং সফ্টওয়্যার বিকাশ কখনই একটি সঠিক বিজ্ঞান হতে যাচ্ছে না।
রোলিং ব্যাক একটি ইন্টারলিউড
যখন পরীক্ষাগুলি ক্রমাগত একীকরণের অংশ হিসাবে চালানো হয়, এবং এমনকি যখন পরীক্ষাগুলি স্ট্যাটাস চেকের অংশ হিসাবে চালানো হয়, তখন এটি সম্ভব যে বিল্ডটি একটি "লাল" অবস্থায় শেষ হয়, বা অন্য একটি অবস্থা যার মানে পরীক্ষাগুলি ব্যর্থ হচ্ছে। পূর্বে উল্লিখিত হিসাবে, এটি অনেক কারণে ঘটতে পারে, যার মধ্যে রয়েছে পরীক্ষা জমা দেওয়ার ক্ষেত্রে রেসের শর্ত, বা ফ্ল্যাকি পরীক্ষা।
ছোট প্রকল্পের জন্য, আপনার প্রবৃত্তি এটিকে একটি সংকট হিসাবে বিবেচনা করতে পারে! সবকিছু বন্ধ করুন, আপত্তিকর পরিবর্তনটি ফিরিয়ে দিন বা প্রত্যাবর্তন করুন এবং একটি পরিচিত ভাল অবস্থায় ফিরে যান। এটি একটি বৈধ পদ্ধতি হতে পারে , তবে এটি মনে রাখা গুরুত্বপূর্ণ যে পরীক্ষা (এবং সাধারণভাবে সফ্টওয়্যার!) শেষের একটি উপায় , নিজের মধ্যে একটি উদ্দেশ্য নয়। আপনার লক্ষ্য সম্ভবত সফ্টওয়্যার লেখা, সব পরীক্ষা পাস করা না. পরিবর্তে, আপনি ব্যর্থ পরীক্ষাগুলিকে ঠিক করে এমন আরেকটি পরিবর্তনের সাথে ব্রেকিং পরিবর্তন অনুসরণ করে এগিয়ে যেতে পারেন।
অন্যদিকে, আপনি হয়ত দেখেছেন, বা কাজ করেছেন, এমন বড় প্রকল্প যা চিরকাল ভাঙা অবস্থায় রয়েছে। বা আরও খারাপ, বৃহৎ প্রজেক্টের একটি অস্পষ্ট পরীক্ষা রয়েছে যা ডেভেলপারদের মধ্যে অ্যালার্ম ক্লান্তি সৃষ্টি করতে প্রায়ই যথেষ্ট বিরতি দেয়। এটি প্রায়শই নেতাদের সমাধান করার জন্য একটি অস্তিত্বগত সমস্যা: এই পরীক্ষাগুলি এমনকি বন্ধ করা যেতে পারে কারণ সেগুলিকে "উন্নয়নের পথে আসা" হিসাবে দেখা হয়।
এটির জন্য কোন দ্রুত সমাধান নেই, তবে এটি আরও আত্মবিশ্বাসী লেখার পরীক্ষা (আপস্কিলিং) হতে এবং পরীক্ষার সুযোগ (সরলীকরণ) কমাতে সাহায্য করতে পারে যাতে ব্যর্থতাগুলি আরও সহজে সনাক্ত করা যায়। কম্পোনেন্ট টেস্ট বা ইন্টিগ্রেশন টেস্টের বর্ধিত সংখ্যা ( টাইপস অফ স্বয়ংক্রিয় পরীক্ষার প্রকারগুলিতে আরও বেশি) একটি বিশাল এন্ড-টু-এন্ড পরীক্ষার চেয়ে বেশি আত্মবিশ্বাস প্রদান করতে পারে যা বজায় রাখা কঠিন এবং একবারে সবকিছু করার চেষ্টা করে।
সম্পদ
আপনার উপলব্ধি পরীক্ষা করুন
এনপিএম এবং অনুরূপ প্রোগ্রামগুলি পরীক্ষার সময় যে বিশেষ স্ক্রিপ্টের সন্ধান করে তার নাম কী?