ফ্ল্যাকি টেস্ট স্যুটের কেস

আমি সম্প্রতি একটি টেস্ট স্যুটে কাজ করেছি যেটি অবিশ্বস্ততার কারণে ব্যবহার করা সত্যিই হতাশাজনক ছিল৷

পরীক্ষার স্যুটটি যে অ্যাপ্লিকেশনটিকে লক্ষ্য করে তা ছিল একটি Rails API-শুধুমাত্র অ্যাপ্লিকেশন। পরীক্ষাগুলি জাভাস্ক্রিপ্টে চকরাম নামক একটি ফ্রেমওয়ার্ক ব্যবহার করে লেখা হয়েছিল, "একটি API টেস্টিং ফ্রেমওয়ার্ক যা JSON REST এন্ডপয়েন্টে এন্ড টু এন্ড টেস্ট করার জন্য ডিজাইন করা হয়েছে।"

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

এই বিশেষ টেস্ট স্যুটটি প্রথম রানে পাস করবে, দ্বিতীয় রানে পাস করবে, তারপর তৃতীয় রানে ব্যর্থ হবে, অ্যাপ্লিকেশন কোড বা টেস্ট কোডে কোনো পরিবর্তন না করেই।

আমি আবিষ্কার করেছি যে আমি rake db:reset করে টেস্ট স্যুটটিকে পাসিংয়ে ফিরিয়ে আনতে পারি . পরীক্ষাগুলি, যা রেল অ্যাপ্লিকেশনের উন্নয়ন পরিবেশে পরিচালিত হয় এবং পরীক্ষার পরিবেশের উপর নয়, রেল অ্যাপ্লিকেশনের ডাটাবেস একটি নির্দিষ্ট অবস্থায় থাকার উপর নির্ভর করে যখন টেস্ট স্যুটটি চলতে শুরু করে৷

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

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

এর পরিবর্তে কি করা উচিত ছিল

তাই যদি এই টেস্ট স্যুটটি একটি সমস্যাযুক্ত উপায়ে সেট আপ করা হয়, তাহলে এটি করার সঠিক উপায় কি হত?

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

টেস্ট স্যুটটি রেল অ্যাপ্লিকেশনের পরীক্ষার পরিবেশকে লক্ষ্য করা উচিত এবং উন্নয়ন পরিবেশ নয়। ডেভেলপমেন্ট এনভায়রনমেন্টে একজন ডেভেলপারের ক্রিয়াকলাপ পরীক্ষা স্যুটের কাজে হস্তক্ষেপ করা উচিত নয় এবং এর বিপরীতে।

অন্যান্য ধরনের সমস্যাযুক্ত নির্ভরতা

আমার গল্পে, সমস্যাযুক্ত নির্ভরতা একটি ডাটাবেস যা সঠিকভাবে পরিষ্কার করা হচ্ছিল না।

অন্য ধরনের সমস্যাযুক্ত নির্ভরতা একটি নেটওয়ার্ক অনুরোধ। কল্পনা করুন আপনার কাছে একটি টেস্ট স্যুট আছে যা Twilio API-কে আঘাত করে। আপনি মঙ্গলবার পরীক্ষা স্যুট চালান এবং এটি পাস হয়। তারপর বুধবার আপনি একই পরীক্ষা স্যুট চালান এবং এটি ব্যর্থ হয়। আপনার অজানা, Twilio একটি বিভ্রাট হচ্ছে, এবং সেই কারণে আপনার পরীক্ষা স্যুট ব্যর্থ হয়েছে. কয়েক মিনিট পরে বিভ্রাট সমাধান করা হয় এবং আপনার পরীক্ষা স্যুট আবার পাস হয়।

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

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

কেস যখন বাইরের নির্ভরতা ঠিক থাকে

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

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

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

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