আমি gầnে একটি টেস্ট স্যুটের সাথে কাজ করেছি যা এর অনিয়মিততার কারণে খুব ঝামেলাদার ছিল।
টেস্ট স্যুটটি যে অ্যাপ্লিকেশনকে টার্গেট করছিল তা একটি রেইলস API-অনلی অ্যাপ্লিকেশন। টেস্টগুলো জাভাস্ক্রিপ্টে লেখা ছিল Chakram ফ্রেমওয়ার্ক ব্যবহার করে — "একটি API টেস্টিং ফ্রেমওয়ার্ক যা JSON REST এন্ডপয়েন্ট-এ এন্ড-টু-এন্ড টেস্ট করার জন্য ডিজাইন করা হয়েছে"।
টেস্ট স্যুটটির সমস্যা ছিল এটি ডিটারমিনিস্টিক নয়। একটি ফাংশন বা প্রোগ্রাম ডিটারমিনিস্টিক হয় যদি, একই ইনপুট দিলে এটি সবসময় একই আউটপুট দেয়।
এই নির্দিষ্ট টেস্ট স্যুট প্রথম রানে পাস করত, দ্বিতীয় রানে পাস করত, তারপর তৃতীয় রানে ফেইল করত — অ্যাপ্লিকেশন কোড বা টেস্ট কোডে কোনো পরিবর্তন ছাড়া।
আমি আবিষ্কার করলাম যে rake db:reset করলে টেস্ট স্যুট আবার পাস করতে শুরু করে। টেস্টগুলো রেইলস অ্যাপ্লিকেশনের ডেভেলপমেন্ট এনভায়রনমেন্টে অপারেট করত (টেস্ট এনভায়রনমেন্টে নয়), এবং রেইলস অ্যাপ্লিকেশনের ডেটাবেস টেস্ট স্যুট শুরু হয়ার সময় একটি নির্দিষ্ট অবস্থায় থাকতে হতো।
কখনও কখনও আমি ফ্রেশলি সিডেড ডেটাবেস দিয়ে শুরু করতাম, টেস্ট স্যুট রান করতাম, এবং দ্বিতীয়বারও সফলভাবে রান করতাম। হয়তো তিন বা ততোধিক বারও রান করতে পারতাম। কিন্তু অনেক সময় টেস্ট স্যুট ডেটা গুলো হালনাগাদ করত এবং আমাকে আবার rake db:reset করতে হতো ডেটা টেস্ট স্যুটের উপযোগী অবস্থায় ফিরিয়ে আনতে।
এটি অবশ্যই সঠিক পদ্ধতি নয়। একটি টেস্ট স্যুট শুধু এককারণে ফেইল হওয়া উচিত: যে কোডটি টেস্ট করছে সেটি ঠিকমতো কাজ করা বন্ধ করলে।
বদলে কী করা উচিত ছিল
যদি এই টেস্ট স্যুট проблемামূলকভাবে সেট আপ করা হয়, তবে সঠিক পদ্ধতি কী হতো?
সমস্যার মূল কারণ ছিল টেস্ট স্যুটটি ডেটাবেস রিসেটের জন্য ম্যানুয়ালি একজন মানুষের ওপর নির্ভর করত। বদলে, টেস্ট স্যুটের প্রতিটি আলাদা টেস্ট উচিত ছিল স্বয়ংক্রিয়ভাবে ডেটাবেসকে ক্লিন এবং রেডি অবস্থায় আনে রান করার আগে। (টেস্ট রান করার পর ডেটাবেস ওইপ করাও স্বাভাবিক যাতে অন্য টেস্টে এর ডেটা "লিক" না করে। যদি প্রতিটি টেস্ট রান করার আগে ডেটাবেস ক্লিয়ার করে, তবে এটি স্ট্রিক্টলি জরুরি নয়, কিন্তু এটি একটি ভালো প্রটেক্টিভ মেজার।)
টেস্ট স্যুটটিকে রেইলস অ্যাপ্লিকেশনের টেস্ট এনভায়রনমেন্ট টার্গেট করা উচিত ছিল, ডেভেলপমেন্ট এনভায়রনমেন্ট নয়। একজন ডেভেলপারের ডেভেলপমেন্ট এনভায়রনমেন্টে কাজ টেস্ট স্যুটের কাজে বাধা দিতে পারত না এবং বিপরীতটিও।
অন্যান্য ধরনের সমস্যামূলক ডিপেন্ডেন্সি
আমার গল্পে, সমস্যামূলক ডিপেন্ডেন্সি ছিল ডেটাবেস যা সঠিকভাবে ক্লিন হচ্ছিল না।
অন্য একটি সমস্যামূলক ডিপেন্ডেন্সি হলো নেটওয়ার্ক রিকুয়েস্ট। কল্পনা করুন আপনার একটি টেস্ট স্যুট আছে যা Twilio API হিট করে। আপনি মঙ্গলবার টেস্ট স্যুট রান করলেন এবং পাস করল। বুধবার একই টেস্ট স্যুট রান করলেন এবং ফেইল করল। আপনার জ্ঞানাতীত Twilio-র আউটেজ চলছে, এবং তাই আপনার টেস্ট স্যুট ফেইল করল। কিছু মিনিট পর আউটেজ ফিক্স হয়ে গেল এবং আপনার টেস্ট স্যুট আবার পাস করল।
এটি আবার একই ধারণার দিকে ফেরত যাচ্ছে যে একটি টেস্ট শুধু এককারণে ফেইল হওয়া উচিত, এবং সেটি হলো আপনার অ্যাপ্লিকেশন কোড কাজ করা বন্ধ করলে।
আপনি যদি নেটওয়ার্কের সাথে ইন্টারঅ্যাক্ট করার কোডের জন্য টেস্ট লিখতে চান, তবে একটি ভালো পদ্ধতি (রুবি/রেইলস ব্যবহার করলে) হলো VCR-এর মতো টুল ব্যবহার করা যা নেটওয়ার্ক রিকুয়েস্ট রেকর্ড করে এবং পরে ইন্টারনেট ছাড়া সেগুলো রিপ্লে করে।
বাহ্যিক ডিপেন্ডেন্সি গ্রহণযোগ্য হয় এমন কেসগুলো
দাড়িয়া যেতে পারে যে যদি একটি অ্যাপ্লিকেশন Twilio API-র ওপর নির্ভরশীল থাকে এবং Twilio API ডাউন থাকে, তবে অ্যাপ্লিকেশনটিই বাসতবে ব্রোকেন রয়েছে এবং তাই টেস্টটিই ফেইল হওয়া উচিত। আমরা এই ধারণাটি টেস্টগুলো বাহ্যিক কন্ডিশনে নির্ভরশীল হওয়া উচিত নয় — এই দুটো কীভাবে মেলাব?
এই দুটো মেলানোর পথ হলো ইন্টিগ্রেশন টেস্ট (যে একাধিক লেয়ার বা সিস্টেম একসাথে টেস্ট করে) এবং ইউনিট টেস্ট (যে একক ফাংশনালিটি আইসোলেশন-এ টেস্ট করে) — এই দুটির মধ্যে পার্থক্য করা।
যদি একটি تیم সচেতনভাবে সিদ্ধান্ত নেয় যে তাদের টেস্টের একটি নির্দিষ্ট সেট এক্সটারনাল সার্ভিস হিট করবে নেটওয়ার্কের মাধ্যমে যাতে একাধিক সিস্টেম একসাথে টেস্ট করা যায়, তবে এতে কিছু "ভুল" নেই। (বিকল্প হতো সেসিস্টেমগুলো একসাথে টেস্ট করার চেষ্টা 아예 না করা।) এই সিনেরিওতে টিমকে শুধু জানতে হবে যে তাদের নেটওয়ার্ক-ডিপেন্ডেন্ট ইন্টিগ্রেশন টেস্ট স্যুট ডিটারমিনিস্টিক হওয়ার গ্যারান্টি দেয় না এবং সম্ভবত কখনও কখনও ফ্ল্যাকি হব। এই ধরনের টেস্ট স্যুট ডেভেলপাররা যেটা প্রতিদিন রান করে রিগ্রেশন চেক করার জন্য সেটা থেকে আলাদা থাকা উচিত।
বাহ্যিক কন্ডিশনে টেস্ট নির্ভরশীল না হওয়ার নিয়মের এক্সেপশন থাকলেও, অধিকাংশ সময় নিয়মটি মেনে চলা উচিত, যাতে আপনার টেস্ট স্যুট ডিটারমিনিস্টিক এবং বিশ্বস্ত হয়।
