৩টি বিষয় যা BDD সম্পর্কে কেউ আপনাকে বলে না
আপনার Cucumber suite চালাতে চল্লিশ মিনিট সময় লাগে। কোডের অনেক স্তর না পড়ে আপনি একটি মাত্র feature file কী টেস্ট করছে তা ব্যাখ্যা করতে পারেন না।
অনেক টিম BDD গ্রহণ করে কারণ বিজনেস স্টেকহোল্ডারদের টেস্টগুলো পড়া প্রয়োজন হয়। তারপর, সেই স্টেকহোল্ডাররা পড়া বন্ধ করে দেয়। এর ফলে আপনি একটি মেইনটেন্যান্স nightmare-এর সম্মুখীন হন।
BDD সম্পর্কে তিনটি সত্য নিচে দেওয়া হলো।
১. Gherkin কোনো প্রোগ্রামিং ল্যাঙ্গুয়েজ নয়
Gherkin-এ টেস্ট স্ক্রিপ্ট লেখা বন্ধ করুন। যদি আপনার scenarios-এ প্রতিটি ক্লিক এবং প্রতিটি ফিল্ডের তালিকা থাকে, তবে আপনি ভুল করছেন।
Bad Gherkin:
- Given ব্যবহারকারী "test@example.com" ইমেলটি প্রবেশ করান
- And ব্যবহারকারী "Password123!" পাসওয়ার্ডটি প্রবেশ করান
- And ব্যবহারকারী "Place Order" বাটনে ক্লিক করেন
Good Gherkin:
- Given ব্যবহারকারীর কেনাকাটার জন্য আইটেম প্রস্তুত আছে
- When ব্যবহারকারী একটি বৈধ ক্রেডিট কার্ড দিয়ে পেমেন্ট করেন
- Then অর্ডারটি নিশ্চিত করা হয়
"কীভাবে" (how) বিষয়টি থাকে আপনার step definitions-এ। "কী" (what) বিষয়টি থাকে আপনার feature files-এ। আপনার feature files গুলো সহজ রাখুন যাতে একজন প্রোডাক্ট ম্যানেজার কয়েক সেকেন্ডের মধ্যেই সেগুলো পড়ে বুঝতে পারেন।
২. Step definitions কোনো dependency graph নয়
একটি step definition যেন অন্য step definition-কে import না করে। এটি একটি জটিল জট তৈরি করে। যদি একটি step ফেইল করে, তবে তা পুরো স্টেটকে (state) নষ্ট করে দেয়।
সমাধানটি সহজ:
- আপনার page objects গুলোকে step definitions থেকে আলাদা করুন।
- একটি shared domain layer ব্যবহার করুন।
- Step definitions হওয়া উচিত পাতলা wrapper যা domain objects-কে কল করে।
এটি আপনার steps গুলোকে stateless করে তোলে। আপনি অন্য কোনো scenario নষ্ট না করেই আপনার কোডের একটি অংশ পরিবর্তন করতে পারবেন।
৩. BDD হলো একটি ডকুমেন্টেশন প্রজেক্ট
BDD হলো যোগাযোগের বিষয়, শুধু টেস্টিং নয়। টেস্ট হলো এর একটি পার্শ্বপ্রতিক্রিয়া (side effect)।
আপনি যদি শুধুমাত্র test coverage বা execution speed-এর জন্য অপ্টিমাইজ করেন, তবে আপনি মূল লক্ষ্যটি হারিয়ে ফেলবেন। আপনার system বোঝার জন্য একজন নতুন ইঞ্জিনিয়ারের প্রথম কাজ হওয়া উচিত আপনার feature files পড়া।
যদি একজন ব্যক্তি আপনার feature files পড়ে আপনার system বুঝতে না পারেন, তবে আপনার BDD suite ব্যর্থ হয়েছে।
আগামীকাল কী করবেন:
- আপনার সবচেয়ে খারাপ feature file-টি বেছে নিন।
- Scenarios গুলোকে তিন থেকে পাঁচ লাইনের মধ্যে নিয়ে আসার জন্য পুনরায় লিখুন।
- ডেটাগুলোকে step definitions বা factories-এ সরিয়ে নিন।
- step-to-step import-এর পরিবর্তে domain objects ব্যবহার করুন।
আপনি কি মাত্র পাঁচ মিনিটে শুধুমাত্র আপনার feature files ব্যবহার করে একজন নতুন নিয়োগপ্রাপ্তকে আপনার system সম্পর্কে বুঝিয়ে বলতে পারবেন? যদি না পারেন, তবে পুনরায় লেখা শুরু করুন।
আপনার Cucumber স্যুট রক্ষণাবেক্ষণের দুঃস্বপ্নে পরিণত হওয়ার আগে BDD সম্পর্কে ৩টি বিষয় যা কেউ আপনাকে বলে না
BDD (Behavior-Driven Development) শুনতে খুব চমৎকার মনে হয়। এটি ডেভেলপার, QA এবং স্টেকহোল্ডারদের মধ্যে একটি সাধারণ ভাষা তৈরি করতে সাহায্য করে। কিন্তু বাস্তবে, এটি প্রায়শই একটি রক্ষণাবেক্ষণের দুঃস্বপ্নে (maintenance nightmare) পরিণত হয়।
আপনি যদি আপনার Cucumber স্যুটকে দীর্ঘমেয়াদে কার্যকর রাখতে চান, তবে এই ৩টি বিষয় আপনার জানা অত্যন্ত জরুরি।
১. Gherkin-এর ফাঁদ (The Gherkin Trap)
অনেকেই Gherkin সিনারিও লেখার সময় অতিরিক্ত বিস্তারিতভাবে লিখতে শুরু করেন। তারা "কী করা হচ্ছে" (what) এর পরিবর্তে "কীভাবে করা হচ্ছে" (how) তা লিখতে থাকেন।
যখন আপনি প্রতিটি ছোটখাটো UI ইন্টারঅ্যাকশন বা টেকনিক্যাল ধাপ Gherkin-এ লিখে ফেলেন, তখন আপনার সিনারিওগুলো অত্যন্ত ভঙ্গুর (brittle) হয়ে পড়ে। সামান্যতম UI পরিবর্তন বা টেকনিক্যাল পরিবর্তনের কারণে আপনার সমস্ত টেস্ট কেস ভেঙে পড়বে।
সমাধান: সিনারিওগুলোকে উচ্চ-স্তরের (high-level) রাখুন। Gherkin-এ ব্যবসার উদ্দেশ্য বা 'what' বর্ণনা করুন, টেকনিক্যাল ইমপ্লিমেন্টেশন বা 'how' নয়।
২. Step Definition-এর বিস্ফোরণ (The Step Definition Explosion)
আপনি যখন প্রতিটি নতুন সিনারিওর জন্য নতুন নতুন Step Definition লিখতে শুরু করেন, তখন আপনার প্রজেক্টে হাজার হাজার লাইন কোড জমা হতে থাকে। এর ফলে একই কাজ করার জন্য একাধিক Step Definition তৈরি হয়, যা কোডবেসকে অগোছালো এবং রক্ষণাবেক্ষণ করা কঠিন করে তোলে।
এটি একটি চক্রাকার সমস্যা তৈরি করে: নতুন সিনারিও $\rightarrow$ নতুন স্টেপ $\rightarrow$ আরও বেশি কোড $\rightarrow$ আরও বেশি রক্ষণাবেক্ষণ।
সমাধান: রিইউজেবল (reusable) স্টেপ তৈরির দিকে মনোযোগ দিন। একটি স্টেপ যেন বিভিন্ন সিনারিওতে ব্যবহার করা যায় সেভাবে ডিজাইন করুন। আপনার স্টেপগুলোকে এমনভাবে লিখুন যেন তারা ছোট ছোট এবং বহুমুখী (versatile) হয়।
৩. নিরাপত্তার মিথ্যা ধারণা (The False Sense of Security)
সবচেয়ে বিপজ্জনক বিষয় হলো, আপনার সব টেস্ট পাস করছে মানেই আপনার সফটওয়্যার ঠিক আছে—এমন ধারণা করা।
যদি আপনার Gherkin সিনারিওগুলো ভুলভাবে লেখা হয় বা ব্যবসার আসল প্রয়োজনীয়তা (business requirements) সঠিকভাবে প্রতিফলিত না করে, তবে আপনার টেস্টগুলো কেবল একটি মিথ্যা নিরাপত্তার অনুভূতি দেবে। আপনি হয়তো খুব নিখুঁতভাবে এমন কিছু টেস্ট করছেন যা আসলে ব্যবসার কোনো কাজে আসছে না বা ভুল ফিচার টেস্ট করছে।
সমাধান: সিনারিওগুলো লেখার আগে স্টেকহোল্ডারদের সাথে আলোচনা করুন যাতে নিশ্চিত হওয়া যায় যে আপনি সঠিক বিজনেস ভ্যালু (business value) টেস্ট করছেন। মনে রাখবেন, BDD-এর মূল লক্ষ্য হলো কোড টেস্ট করা নয়, বরং সঠিক আচরণ (behavior) নিশ্চিত করা।
উপসংহার
BDD একটি শক্তিশালী টুল, যদি এটি সঠিকভাবে ব্যবহার করা হয়। এটি কেবল একটি অটোমেশন ফ্রেমওয়ার্ক নয়, এটি একটি যোগাযোগের মাধ্যম। যদি আপনি সিনারিওগুলোকে অতিরিক্ত টেকনিক্যাল না করে ব্যবসার প্রয়োজনের ওপর ভিত্তি করে লেখেন, তবেই আপনি রক্ষণাবেক্ষণের দুঃস্বপ্ন থেকে মুক্তি পাবেন।