ভিজ্যুয়াল ব্যবসায়িক লজিক টেস্টিং: প্রথমে কী স্বয়ংক্রিয় করবেন

ভিজ্যুয়াল ব্যবসায়িক লজিক নিয়ে সাধারণ সমস্যা

ভিজ্যুয়াল ওয়ার্কফ্লো দেখতে নিরাপদ মনে করায় কারণ লজিকটি দেখা যায়। তবুও এগুলো প্রায়ই বদলায়, এবং ছোট পরিবর্তনগুলিই সত্যিকারের ইউজার পাথ ভেঙে দেয়। এজন্যই নো-কোড টুলেই ভিজ্যুয়াল ব্যবসায়িক লজিক টেস্টিং দরকার।

যা প্রায়ই ভেঙে পড়ে তা ওয়ার্কফ্লো-এর “বড় আইডিয়া” নয়, বরং ছোট সংযোগগুলো: একটি কন্ডিশন উল্টে যায় ("AND" বনাম "OR"), ডিফল্ট মান বদলে যায়, একটি স্টেপ ভুল ক্রমে চলে, বা একটি এরর ব্রাঞ্চ স্কিপ হয়ে যায়। AppMaster-এ এটা দেখা যায় যখন একটি Business Process এডিট করা হয়, Data Designer ফিল্ড রিনেইম করা হয়, বা একটি API রেসপন্সের আকার পরিবর্তিত হয়।

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

লক্ষ্য হচ্ছে দ্রুত ফিডব্যাক, কিন্তু সবকিছু টেস্ট না করে। একটি ছোট সেট স্বয়ংক্রিয় চেক চান যা মূল লজিক বদলে গেলে চিৎকার করবে, আর এজ কেস ও ভিজ্যুয়াল পলিশ ম্যানুয়ালে রেখে দেবে।

কভারেজকে তিনটি পরস্পর-সমর্থনশীল স্তরে ভেবে নেওয়া প্রায়োগিক:

• ওয়ার্কফ্লো-লেভেল টেস্ট যেগুলো কী পাথগুলো end-to-end চালায় (submit request -> validate -> approve -> notify).
• API কন্ট্রাক্ট চেক যা নিশ্চিত করে ইনপুট ও আউটপুটগুলো UI এবং ইন্টিগ্রেশনগুলোর প্রত্যাশার সাথে মেলে।
• পুনরাবৃত্তিযোগ্য টেস্ট ডেটা যা মডেল বদলালে ও কাজ করে।

উদাহরণ: একটি সাপোর্ট অ্যাপে “refund approval” ওয়ার্কফ্লো থাকলে প্রতিটি স্ক্রিন টেস্ট করার দরকার নেই। আপনাকে নিশ্চিত হতে হবে যে লিমিট অতিক্রান্ত অনুরোধগুলো সর্বদা ম্যানেজারের কাছে যায়, স্ট্যাটাস সঠিকভাবে আপডেট হয়, এবং ইমেইল বা Telegram-এ পাঠানো মেসেজে সঠিক ফিল্ড আছে।

ওয়ার্কফ্লো, API, এবং UI-এর জন্য একটি সরল টেস্টিং মানচিত্র

যখন আপনি যা টেস্ট করছেন (লজিক) কে সেটা কোথায় রান হয় (ওয়ার্কফ্লো, API, বা UI) থেকে আলাদা করেন, টেস্ট করা সহজ হয়। লক্ষ্য সবকিছু সব জায়গায় টেস্ট করা নয়; বরং সেই সবচেয়ে ছোট টুকরো বেছে নেওয়া যা প্রমাণ করে ফিচারটি এখনও কাজ করে।

“ইউনিট-স্টাইল” লজিক চেকগুলো একবারে একটি রুল ফোকাস করে: একটি ক্যালকুলেশন, একটি কন্ডিশন, একটি স্ট্যাটাস পরিবর্তন। এগুলো দ্রুত এবং ব্রেক পয়েন্ট নির্ধারণে ভালো, কিন্তু একাধিক স্টেপ জোড়া লাগলে যে সমস্যা দেখা দেয় তা মিস করে।

ওয়ার্কফ্লো-লেভেল টেস্ট হলো মাঝখানের স্তর। আপনি একটি ক্লিয়ার স্টেট থেকে শুরু করেন, বাস্তবসম্মত ইনপুট ওয়ার্কফ্লোতে পাঠান, এবং যে আউটকামগুলো গুরুত্বপূর্ণ সেগুলোassert করেন (তৈরি রেকর্ড, স্ট্যাটাস পরিবর্তন, পাঠানো নোটিফিকেশন, প্রত্যাখ্যান করা অ্যাকশন)। AppMaster-এ প্রায়শই এর অর্থ হলো Business Process কে end-to-end এক্সারসাইজ করা UI ক্লিক না করেই।

এন্ড-টু-এন্ড UI টেস্ট উপরে বসে থাকে। এগুলো wiring সমস্যাগুলো ধরতে পারে, কিন্তু ধীর ও ভঙ্গুর—কারণ ছোট UI পরিবর্তনও এগুলো ভাঙিয়ে দিতে পারে এমনকি লজিক ঠিক থাকলেও। যদি আপনি কেবল UI টেস্টের উপর নির্ভর করেন, তাহলে আপনি বাগ খোঁজার চাইতে টেস্ট ফিক্স করতে বেশি সময় ব্যয় করবেন।

সবচেয়ে ছোট নির্ভরযোগ্য টেস্ট স্লাইস বেছে নিলে, এই ক্রম ভালো কাজ করে:

• ফিচার যদি একাধিক স্টেপ বা রোল ছাড়িয়ে যায় তাহলে ওয়ার্কফ্লো-লেভেল টেস্ট দিয়ে শুরু করুন।
• UI বা ইন্টিগ্রেশনগুলো একই এন্ডপয়েন্টে নির্ভর করে থাকলে একটি API কন্ট্রাক্ট চেক যোগ করুন।
• UI টেস্ট কেবল ১–২টি ক্রিটিক্যাল ইউজার পাথের জন্য ব্যবহার করুন (লগইন, চেকআউট, রিকোয়েস্ট সাবমিট)।
• জটিল নিয়ম (থ্রেশহোল্ড, পারমিশন, এজ কেস) এর জন্য ইউনিট-স্টাইল চেক ব্যবহার করুন।

উদাহরণস্বরূপ একটি অনুমোদন প্রক্রিয়ার জন্য এটি বলতে পারেন: একটি ওয়ার্কফ্লো টেস্ট যা রিকোয়েস্টকে Draft থেকে Approved পর্যন্ত নিয়ে যায়, একটি কন্ট্রাক্ট চেক যা status ফিল্ডটি কনসিস্টেন্ট রাখে, এবং একটি UI টেস্ট যা প্রমাণ করে ইউজার একটি রিকোয়েস্ট সাবমিট করতে পারে।

প্রথমে কী স্বয়ংক্রিয় করবেন (আর কী আপাতত ম্যানুয়াল রাখবেন)

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

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

ফ্রিকোয়েন্সিও গুরুত্বপূর্ণ। প্রতিদিন হাজার বার চলা একটি ওয়ার্কফ্লো (অর্ডার ক্রিয়েশন, টিকিট রুটিং, পাসওয়ার্ড রিসেট) বারবার হওয়ায় তা দ্রুত স্বয়ংক্রিয় হওয়া উচিত, যেখানে মাসে একবারের একজন অ্যাডমিন প্রসেস অপেক্ষা করতে পারে।

টেস্ট লেখার আগে আউটকামটি মাপযোগ্য করুন। একটি ভালো স্বয়ংক্রিয় টেস্ট হয় না “এটা ঠিক দেখায়।” এটি হয় “রেকর্ড X অবস্থান Y-তে শেষ হয়, এবং এই সাইড-এফেক্টগুলো একবারই ঘটেছে।” AppMaster Business Processes এর জন্য এটি ইনপুট, প্রত্যাশিত স্ট্যাটাস পরিবর্তন, এবং প্রত্যাশিত কল বা মেসেজে পরিষ্কার অনুবাদ পায়।

কী স্বয়ংক্রিয় করবেন তার দ্রুত ফিল্টার:

• ভুল হলে উচ্চ প্রভাব (টাকা, অ্যাক্সেস, সংবেদনশীল ডেটা)
• অনেক শাখা বা একাধিক বাহ্যিক সার্ভিস জড়িত
• ঘন ঘন চলে বা বহু ব্যবহারকারীকে প্রভাবিত করে
• পরে ডিবাগ করা কষ্টসাধ্য (নীরব ব্যর্থতা, অ্যাসিঙ্ক স্টেপ)
• এক বাক্যেই লিখে দেওয়া যায় এমন ক্লিয়ার পাস/ফেইল

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

বাস্তব লজিক ভাঙা ধরার জন্য ওয়ার্কফ্লো-লেভেল টেস্ট

ওয়ার্কফ্লো-লেভেল টেস্টগুলো ইউনিট-স্টাইল চেকের এক ধাপ উর্ধ্বে থাকে। এগুলো একটি ওয়ার্কফ্লোকে ব্ল্যাক-বক্স হিসেবে দেখে: সেটি ট্রিগার করুন, তারপর ফাইনাল স্টেট এবং সাইড-এফেক্টগুলো যাচাই করুন। এখানেই আপনি ব্যবহারকারীরা আসলে অনুভব করা ব্রেকগুলো ধরবেন।

একটি ট্রিগার এবং একটি গুরুত্বপূর্ণ আউটকাম নামকরণ করে শুরু করুন। উদাহরণ: “যখন একটি রিকোয়েস্ট সাবমিট করা হয়, স্ট্যাটাস Pending হয় এবং একটি approver জানানক।” যদি এটা সত্য থাকে, ছোট অভ্যন্তরীণ রিফ্যাক্টর সাধারণত সমস্যা না করে।

ফলাফল বদলে দেওয়া শাখাগুলো কভার করুন, প্রতিটি নোড নয়। একটি কমপ্যাক্ট সেট:

• Success path (সবকিছু ভ্যালিড, ইউজার অনুমোদিত)
• Validation failure (মিসিং ফিল্ড, ভুল ফরম্যাট, পরিমাণ রেঞ্জের বাইরে)
• Permission denied (ইউজার দেখতে পারে কিন্তু অ্যাকশন নিতে পারে না)

তারপর সাইড-এফেক্টগুলো যাচাই করুন যা প্রমাণ করে ওয়ার্কফ্লো সত্যিকারের চালানো হয়েছে: PostgreSQL-এ রেকর্ড তৈরি/আপডেট, স্ট্যাটাস ফিল্ড পরিবর্তন, এবং মেসেজ পাঠানো (email/SMS বা Telegram) যদি আপনি সেগুলো ব্যবহার করেন।

টেস্ট ছোট রাখার একটি প্যাটার্ন হল “ট্রিগার, তারপর আউটকাম অ্যাসার্ট”:

• Trigger: ন্যূনতম ইনপুট তৈরি করে ওয়ার্কফ্লো শুরু করুন (API কল, ইভেন্ট, বা বাটন অ্যাকশন)
• Final state: স্ট্যাটাস, owner/assignee, timestamps
• Side effects: নতুন রেকর্ড, অডিট লগ এন্ট্রি, কিউ করা নোটিফিকেশন
• Business rules: লিমিট, প্রয়োজনীয় অনুমোদন, “নিজের রিকোয়েস্ট অনুমোদন করতে পারবে না”
• No surprises: অতিরিক্ত কিছু তৈরি না হওয়া, ডুপ্লিকেট মেসেজ না আসা

এখানে পিক্সেল-পারফেক্ট UI চেক এড়িয়ে চলুন। একটি বাটন সরাতে গেলেও আপনার ব্যবসায়িক নিয়ম বদলায় না। ওয়ার্কফ্লো কী গ্যারান্টি দেয় তা assert করুন, UI কেমন দেখায় তা নয়।

প্রতিটি ওয়ার্কফ্লো টেস্টকে একটিই আউটকামে ফোকাস করুন। যদি একটি টেস্ট পাঁচটি রুল ও তিনটি সাইড-এফেক্ট যাচাই করতে চাই তাহলে সেটি পড়তেও কঠিন এবং ফিক্স করতেও কষ্টকর হবে।

নীরব ব্রেকিং চেঞ্জ আটকাতে API কন্ট্রাক্ট চেক

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

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

কন্ট্রাক্টে কী লক করে রাখা উচিত

প্রথমে সেই জিনিসগুলো ধরুন যা ক্লায়েন্টদের নীরবে ভাঙে:

• সাধারণ আউটকামের জন্য স্ট্যাটাস কোড (success, validation error, forbidden, not found)
• রিকোয়েস্ট ও রেসপন্সের আবশ্যক ফিল্ড (কোনগুলো null হতে পারে)
• ফিল্ড টাইপ ও ফরম্যাট (number বনাম string, তারিখ ফরম্যাট, enum মান)
• ভ্যালিডেশন মেসেজ (সঠিক টেক্সট না—স্টেবল কী/কোড)
• এরর শেপ (এরর কোথায় থাকে, কিভাবে একাধিক এরর রিটার্ন হয়)

উদ্দেশ্যমূলকভাবে নেগেটিভ কেসও অন্তর্ভুক্ত করুন: একটি আবশ্যক ফিল্ড মিসিং, ভুল টাইপ পাঠানো, বা অনুমতি ছাড়া অ্যাকশন চালানো। এইসব টেস্ট সস্তা এবং ওয়ার্কফ্লো ও API’র মধ্যে মিসম্যাচ বের করে দেয়।

AppMaster ব্যবহার করলে কন্ট্রাক্টগুলো আরও বেশি গুরুত্বপূর্ণ হয় যখন আপনি মডেল বা লজিক বদলে পুনরায় অ্যাপ জেনারেট করেন। একটি রিনেইম করা ফিল্ড, শক্ত নিয়ম যুক্ত করা, বা নতুন required attribute পুরনো ক্লায়েন্ট বা ইন্টিগ্রেশন ভেঙে দিতে পারে যদিও ব্যাকএন্ড কম্পাইল ঠিকঠাক চলে।

কন্ট্রাক্ট চেক কোথায় চালাবেন

কমপক্ষে একটি নির্ভরযোগ্য জায়গা বেছে নিন, তারপর দ্রুত ফিডব্যাক চাইলে আরো যোগ করুন:

• CI-তে প্রতিটি চেঞ্জে কোর এন্ডপয়েন্টগুলোর জন্য
• স্টেজিং-এ ডিপ্লয়ের পর পারি-এনভায়রনমেন্ট-সুনির্দিষ্ট সমস্যা ধরতে
• নাইটলি রানের মাধ্যমে বিস্তৃত কভারেজ পেতে (টিমকে ধীর না করে)

কম্প্যাটিবিলিটি প্রত্যাশাও সম্মত করুন। যদি পুরোনো ক্লায়েন্টদের কাজ চালিয়ে যেতে হয়, তাহলে ফিল্ড সরানো বা মান বদলানোকে ভার্সনড পরিবর্তন হিসেবে বিবেচনা করুন—ছোট রিফ্যাক্টর না হিসেবে।

বিশ্বাসযোগ্য পুনরাবৃত্তিযোগ্য টেস্ট ডেটা

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

রোল এবং কোর রেকর্ডগুলো কভার করে এমন একটি ছোট সিড ডেটাসেট রাখুন: একটি Admin user, একটি Manager, একটি সাধারণ Employee, একটি Customer, একটি active Subscription, এবং একটি "সমস্যাজনক কেস" (যেমন overdue invoice)। টেস্টগুলোর মাঝে এই সিডগুলো পুনরায় ব্যবহার করুন যাতে আপনি লজিক যাচাই করতে সময় ব্যয় করেন, ডেটা পুনরাবিষ্কার করতে নয়।

আরও টেস্ট যোগ করার আগে পরিবেশটি কিভাবে ক্লিন স্টেটে ফিরে আসবে তা নির্ধারণ করুন:

• প্রতিটি রানেই টেস্ট পরিবেশ পুরোপুরি পুনর্নির্মাণ (ধীর, খুব পরিষ্কার)
• রানগুলোর মাঝে মূল টেবিলগুলো truncate বা wipe করা (দ্রুত, সাবধানে করতে হয়)
• শুধুমাত্র প্রতিটি টেস্ট যা স্পর্শ করে তা পুনরায় তৈরি (সবচেয়ে দ্রুত, কিন্তু ভুল করা সহজ)

কোর চেকের জন্য রেন্ডমনেস এড়িয়ে চলুন। এক্সপ্লোরেটরি রানের জন্য রেন্ডম নাম, টাইমস্ট্যাম্প, এবং পরিমাণ ঠিক আছে, কিন্তু পাস/ফেইল তুলনা কঠিন করে দেয়। যদি বৈচিত্র্য দরকার হয়, নির্দিষ্ট মান ব্যবহার করুন (উদাহরণ: InvoiceTotal = 100.00) এবং যখন টেস্টটি একটি নিয়ম প্রমাণের উদ্দেশ্যে হয় তখন কেবল একটি ভেরিয়েবল পরিবর্তন করুন।

প্রতি ওয়ার্কফ্লো টেস্টের জন্য ন্যূনতম প্রয়োজনীয় ডেটা লিখে রাখুন: কোন ইউজার রোল, কোন স্ট্যাটাস ফিল্ড, এবং কোন সম্পর্কিত এন্টিটি Business Process শুরু হওয়ার আগে অবশ্যই থাকতে হবে। টেস্ট ফেল করলে দ্রুত বুঝতে পারবেন লজিক কি ভেঙেছে নাকি সেটআপেই সমস্যা হয়েছে।

কিভাবে টেস্টগুলো মডেল পরিবর্তন সহ টিকে থাকবে

মডেল পরিবর্তনই সবচেয়ে বড় কারণ যার জন্য "ভালো" টেস্ট হঠাৎ ভেঙে যায়। আপনি একটি ফিল্ড রিনেইম করেন, একটি টেবিল দুইটায় ভাগ করেন, একটি সম্পর্ক বদলান, বা Data Designer আপডেট করে AppMaster অ্যাপ পুনরায় জেনারেট করেন—তারপর টেস্ট সেটআপ পুরনো শেপে লিখতে থাকে। আরও খারাপ ব্যাপার, টেস্টগুলো ভুল জিনিস যাচাই করেই পাস করে যদি তা ভিড়লুকরূপে ভাঙে।

ডাটাবেস আইডি বা অটো-জেন UUID হার্ডকোড করা একটি সাধারণ ফাঁদ। এগুলো ব্যবসায়িক অর্থ বহন করে না এবং রিসিড, পরিবেশ পুনর্নির্মাণ, বা নতুন এন্টিটি যোগ করলে বদলে যায়। টেস্টগুলোকে ইমেল, অর্ডার নাম্বার, external reference, বা মানব-পঠনযোগ্য কোডের মতো স্থিতিশীল ব্যবসায়িক আইডিতে অ্যাংকর করুন।

বর্তমান মডেল থেকে টেস্ট ডেটা বানান

টেস্ট ডেটাকে একটি ছোট প্রোডাক্ট ফিচারের মতো বিবেচনা করুন। ডেটা বিল্ডার ব্যবহার করুন যা আজকের মডেলের উপর ভিত্তি করে এন্টিটি তৈরি করে, গত মাসের নয়। যখন একটি required ফিল্ড যোগ করবেন, শুধু বিল্ডার একবার আপডেট করুন এবং সকল টেস্ট সে সুবিধা পাবে।

একটি ছোট সেট canonical entity রাখুন যা অ্যাপের সঙ্গে বিকাশ হয়। উদাহরণ: সবসময় একই রোলগুলো (Requester, Approver), একটি বিভাগ, এবং একটি নমুনা কাস্টমার তৈরি করুন। এতে ওয়ার্কফ্লো টেস্টগুলো পাঠযোগ্য থাকে এবং একাধিক এক-অফ ফিক্সচারের ভিড় এড়ায়।

সুইট টিকে রাখতে নিয়মগুলো:

• assertion এ internal ID না ব্যবহার করে business keys (যেমন employee_email) ব্যবহার করুন
• entity creation centralized builders-এ রাখুন (ফিল্ড বদলালে এক জায়গায় আপডেট)
• ৫–১০টি canonical রেকর্ড রাখুন যা বেশিরভাগ ওয়ার্কফ্লো কভার করে
• একটি migration-check টেস্ট রাখুন যা শুধু সিড ডেটা লোড হচ্ছে কি না যাচাই করে
• required ফিল্ড বা relation বদলে গেলে দ্রুত ব্যর্থ করে দিন (স্পষ্ট এরর আউটপুট)

মাইগ্রেশন-চেক টেস্টটি সহজ কিন্তু শক্তিশালী: যদি সিড ডেটা আর মডেলের সাথে ফিট না করে, আপনি তা সঙ্গে সঙ্গেই জানতে পারবেন—শত শত ওয়ার্কফ্লো টেস্ট বিভ্রান্ত করে ফেলার আগেই।

AppMaster প্রকল্পগুলিতে অতিরিক্ত মনোযোগ দরকার কোথায়

AppMaster দ্রুত চলার সুবিধা দেয়, আর এর মানে আপনার অ্যাপ দ্রুত আকার বদলাতে পারে। ভিজ্যুয়াল ও মডেল পরিবর্তনগুলিকে "পরে দেখে নেব" ধাঁচের না করে টেস্টিং ট্রিগার হিসেবে বিবেচনা করুন। ভিজ্যুয়াল ব্যবসায়িক লজিক টেস্টিং তখনই ফলদায়ক যখন আপনি মডেল পরিবর্তনের সময় ব্রেক ধরেন, ব্যবহারকারীর পরে নয়।

Data Designer (PostgreSQL মডেল) এডিট করলে ধরে নিন পুরোনো সিড ডেটা আর ফিট নাও করতে পারে। একটি রিনেইম করা ফিল্ড, নতুন required কলাম, বা বদলানো রিলেশন সেটআপ স্ক্রিপ্ট ভেঙে দিতে পারে এবং টেস্টগুলো ভুল কারণে ফেল করবে। প্রতিটি ডেটা মডেল আপডেটকে সিড ডেটা রিফ্রেশ করার প্রম্পট হিসেবে ব্যবহার করুন যাতে টেস্ট পরিষ্কার, বাস্তবসম্মত বেসলাইনে শুরু হয়।

Business Process Editor আপডেটের ক্ষেত্রেও একই শৃঙ্খলা প্রয়োজন। যদি একটি ওয়ার্কফ্লো বদলে যায় (নতুন ব্রাঞ্চ, নতুন স্ট্যাটাস, নতুন রোল চেক), ওয়ার্কফ্লো-লেভেল টেস্টগুলো সাথে সাথে আপডেট করুন। নাহলে আপনি ভুলভ্রান্ত নিরাপত্তাজনিত অনুভূতি পাবেন: টেস্টগুলো পাস করছে, কিন্তু সেগুলো বাস্তব প্রক্রিয়ার সাথে মেলেনা।

API-গুলোর ক্ষেত্রে এন্ডপয়েন্ট পরিবর্তনকে কন্ট্রাক্ট স্ন্যাপশটের সঙ্গে বেঁধে রাখুন। ইনপুট বা আউটপুট বদলে গেলে একই কাজের সেশনে কন্ট্রাক্ট চেকগুলো আপডেট করুন যাতে ওয়েব বা মোবাইল অ্যাপের জন্য নীরব ব্রেকিং চেঞ্জ না যাবে।

প্রতি টেস্ট পরিবেশে দ্বিগুণ চেক করুন:

• Auth নিয়ম ও রোল (বিশেষত প্র-বিল্ট authentication ব্যবহার করলে)
• Enabled modules (Stripe বা messaging—Telegram/email/SMS)
• ইন্টিগ্রেশন সেটিং ও সিক্রেট, অথবা পরিষ্কার টেস্ট ডাবল ব্যবহার
• ডিপ্লয়মেন্ট অনুমান (Cloud বনাম self-hosted) যা কনফিগকে প্রভাবিত করে

উদাহরণ: আপনি একটি required Department ফিল্ড যোগ করে BP স্টেপ বদলিয়ে approvals auto-route করে দিলেন। সিড ইউজারদের department সহ আপডেট করুন, তারপর approval workflow টেস্ট আপডেট করে নুতন রাউটিং assert করুন। AppMaster ক্লিন সোর্স কোড পুনরায় জেনারেট করে—কিন্তু আপনার টেস্টগুলো আচরণ (আউটপুট, স্ট্যাটাস, অনুমতি) টার্গেট করলে ড্রিফ্ট কম হবে।

আপনার প্রথম নির্ভরযোগ্য টেস্ট স্যুট সেটআপের ধাপে ধাপে পরিকল্পনা

বেছে নিন কি কাজগুলো অবশ্যই চলমান থাকবে—মডেল বা স্ক্রিন বদলালেও। সাধারণত এগুলো সেই ওয়ার্কফ্লো যারা টাকা, অনুমোদন, অ্যাক্সেস, বা গ্রাহক-মুখী প্রতিশ্রুতি সরবরাহ করে।

কিছু ক্রিটিক্যাল ওয়ার্কফ্লো সংক্ষিপ্ত তালিকা লিখে প্রত্যাশিত আউটকাম সোজা ভাষায় সংজ্ঞায়িত করুন। “Invoice approved by a manager creates a payment request” টেস্টযোগ্য; “Approval works” নয়।

প্রতিটি ওয়ার্কফ্লোর জন্য একটি ন্যূনতম সিড ডেটাসেট তৈরি করুন। ছোট এবং নামকৃত রাখুন যাতে লগে সহজে চিহ্নিত হয়: প্রতিটি রোলে একজন ইউজার, একটি অ্যাকাউন্ট, প্রতিটি স্ট্যাটাসের জন্য এক ডকুমেন্ট। AppMaster-এ Data Designer-এ মিলিয়ে রাখুন যাতে ফিল্ডগুলো বিকাশের সঙ্গে সঙ্গেই ডেটা কনসিস্টেন্ট থাকে।

শুরুতেই টপ কয়েকটি ফ্লো end-to-end ওয়ার্কফ্লো-লেভেলে অটোমেট করুন। উদাহরণস্বরূপ: approval workflow শুরু করুন, ম্যানেজারের ডিসিশন সিমুলেট করুন, এবং শেষ অবস্থা চেক করুন (approved, অডিট রেকর্ড তৈরি, নোটিফিকেশন পাঠানো)।

যে ফ্লোগুলো নির্ভর করে তাদের এন্ডপয়েন্টগুলোর জন্য মাত্র কিছু কন্ট্রাক্ট চেক যোগ করুন। আপনি সবকিছু টেস্ট করার চেষ্টা করছেন না—শব্দটি হল শেপ চেঞ্জ ধরা যে ওয়ার্কফ্লো নীরবভাবে ভেঙে দেয়।

চলনযোগ্য রাখতে:

• প্রতিটি রান আগে ডাটাবেস রিসেট করুন (বা আলাদা টেস্ট স্কিমা ব্যবহার করুন)
• ন্যূনতম ডেটা পুনরায় সিড করুন
• প্রতিটি চেঞ্জে টেস্ট চালান, শুধু রিলিজের আগে নয়
• স্পষ্ট ফেল আউটপুট সংরক্ষণ করুন: ওয়ার্কফ্লোর নাম, ইনপুট, ফাইনাল স্টেট
• কভারেজ বাড়ান কেবলমাত্র যখন একটি বাস্তব বাগ প্রবেশ করে বা নতুন ফিচার স্থির হয়

এতে স্যুট ছোট, দ্রুত এবং কাজে লাগার মত থাকবে যখন আপনার ভিজ্যুয়াল লজিক বাড়ে।

ফ্ল্যাকি ওয়ার্কফ্লো টেস্ট তৈরির সাধারণ ভুল

ফ্ল্যাকি টেস্টগুলো না থাকা টেস্টের চেয়েও খারাপ—এগুলো মানুষকে ফলাফল উপেক্ষা করতে শেখায় এবং সত্যিকারের লজিক ব্রেক ছেড়ে যায়। সবচেয়ে বড় কারণ হচ্ছে ওয়ার্কফ্লোকে UI স্ক্রিপ্ট হিসেবে ট্রিট করা না যে একটি ব্যবসায়িক সিস্টেম।

ক্লিকগুলো অতিরিক্ত অটোমেট করা একটি ক্লাসিক ফাঁদ। যদি আপনার টেস্ট প্রমাণ করে যে একটি বাটন চাপা যায়, তা সঠিক আউটকাম ঘটার নিশ্চয়তা দেয় না। একটি ভালো চেক হলো: ওয়ার্কফ্লো কি সঠিক রেকর্ড তৈরি করেছে, সঠিক স্ট্যাটাস সেট করেছে, এবং সঠিক মেসেজ পাঠিয়েছে কি না। AppMaster-এ সাধারণত অর্থাৎ Business Process যে ফল দেয় (ফিল্ড, ট্রানজিশন, সাইড-এফেক্ট) সে গুলো যাচাই করুন, কীভাবে আপনি পেজ নেভিগেট করেছেন তা নয়।

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

মডেল বদলালে ভাঙে এমন অনুমানগুলো এড়ান। আইডি হার্ডকোড করা, রেকর্ড অর্ডারের ওপর নির্ভর করা, অথবা “লিস্ট-এ প্রথম আইটেম” নেওয়া টেস্টগুলো ভঙ্গুর করে তোলে। আপনার কন্ট্রোল করা স্থিতিশীল কী দিয়ে রেকর্ড সিলেক্ট করুন (external reference, ইমেইল, টেস্টে সেট করা কোড)।

শুরুতেই ঠিক করা উচিত প্যাটার্নগুলো:

• কেবল হ্যাপি-পাথ পরীক্ষা করা, ফলে পারমিশন ত্রুটি, মিসিং ফিল্ড, এবং প্রত্যাখ্যাত স্টেটগুলো অনুপস্থিত থাকে
• লজিক প্রমাণ করার জন্য UI ধাপ ব্যবহার করা না করে ওয়ার্কফ্লো ফলাফল ও অডিট ট্রেইল চেক করা
• লাইভ এক্সটার্নাল সার্ভিস (পেমেন্ট, ইমেইল/SMS) ওপর নির্ভর করা ছাড়া স্টাব ব্যবহার না করা
• দীর্ঘজীবী টেস্ট অ্যাকাউন্ট শেয়ার করা
• আইডি হার্ডকোড করা বা সঠিক সোর্টিং/টাইমস্ট্যাম্প আশা করা

যদি একটি অনুমোদন ওয়ার্কফ্লো budget না থাকলে Submit ব্লক করা উচিৎ, তাহলে একটি নেগেটিভ টেস্ট লিখুন যা প্রত্যাশা করে প্রত্যাখ্যান এবং স্পষ্ট এরর স্ট্যাটাস। এক টেস্ট প্রায়ই অনেক রিগ্রেশন ধরে ফেলে যা একরাশ ক্লিক-থ্রু স্ক্রিপ্ট ধরবে না।

আরো টেস্ট যোগ করার আগে দ্রুত চেকলিস্ট

নতুন টেস্ট যোগ করার আগে নিশ্চিত করুন এটি নিজের মূল্যের পর্যাপ্ত—সুইট দ্রুত বৃদ্ধির সবচেয়ে দ্রুত উপায় হলো এমন টেস্ট যোগ করা যা পড়তে কঠিন, পুনরায় চালাতে কঠিন, এবং ভাঙতে সহজ।

প্রতিটি নতুন টেস্টকে ছোট প্রোডাক্ট ফিচার হিসেবে ট্রিট করার অভ্যাস জরুরি: স্পষ্ট লক্ষ্য, স্থিতিশীল ইনপুট, এবং সহজ পাস/ফেইল।

একটি দ্রুত প্রিফ্লাইট চেকলিস্ট:

• আপনি কি প্রত্যাশিত আউটকাম এক বাক্যে বর্ণনা করতে পারেন (উদাহরণ: "An approved request creates an invoice and notifies Finance")?
• আপনি কি ডেটা রিসেট করে টেস্ট তিনবার চালালে একই ফল পাবেন?
• প্রতিটি ক্রিটিক্যাল ওয়ার্কফ্লোর জন্য কি অন্তত একটি নেগেটিভ কেস আছে (মিসিং ফিল্ড, ভুল রোল, লিমিট অতিক্রম) যা নির্দিষ্টভাবে ফেল করবে?
• যদি ওয়ার্কফ্লো একটি API টাচ করে, আপনি কি কন্ট্রাক্ট চেক করছেন (আবশ্যক ফিল্ড, টাইপ, এরর ফরম্যাট), কেবল "200 OK" নয়?
• যদি ডেটা মডেল বদলে যায়, আপনি কি টেস্টটি কয়েকটি কেন্দ্রীভূত জায়গায় (builders/fixtures) আপডেট করবেন, নাকি হার্ড-কোড করা ভ্যালু খুঁজে বের করবেন?

AppMaster-এ কাজ করলে, পুনর্ব্যবহারযোগ্য সেটআপ ধাপগুলো পছন্দ করুন যা টেস্ট রেকর্ডগুলো সেই একই API বা Business Process দিয়ে তৈরি করে যেটা আপনার অ্যাপ ব্যবহার করে। এতে টেস্টগুলো বাস্তব আচরণে কাছাকাছি থাকে এবং মডেল বদলালে ভাঙা কম হয়।

উদাহরণ: অতিরিক্ত না করে একটি অনুমোদন ওয়ার্কফ্লো টেস্ট করা

একটি ইন্টারনাল অনুমোদন অ্যাপ কল্পনা করুন: রিকোয়েস্টার একটি purchase request সাবমিট করে, একটি approver তা রিভিউ করে, এবং রিকোয়েস্টটি পরিষ্কার স্ট্যাটাস ধরে। এটি একটি ভাল শুরু কারণ ভ্যালু সোজা: সঠিক ব্যক্তি রিকোয়েস্টকে সঠিক পরবর্তী স্টেটে নিয়ে যেতে পারছে।

শুরুতে শুধু সেই অ্যাকশনগুলো টেস্ট করুন যেগুলো সবচেয়ে বেশি গুরুত্বপূর্ণ:

• Approve: approver একটি রিকোয়েস্টকে "Pending" থেকে "Approved" তে নিয়ে যেতে পারে এবং অডিট ফিল্ড (who, when) সেট হয়।
• Reject: approver এটিকে "Rejected" করতে পারে এবং একটি কারণ আবশ্যক।
• Request changes: approver এটিকে "Needs changes" এ পাঠাতে পারে এবং রিকোয়েস্টার পুনরায় সাবমিট করতে পারে।

একটি approval endpoint-এ একটি API কন্ট্রাক্ট চেক যোগ করুন কারণ নীরব ব্রেকিং এখানে সবচেয়ে দুঃখজনক। উদাহরণস্বরূপ, যদি আপনার ওয়ার্কফ্লো POST /requests/{id}/approve কল করে, যাচাই করুন:

• রেসপন্স কোড (সাফল্যের জন্য 200, ভুল রোলে 403)
• রেসপন্স শেপ (status একটি পরিচিত মান, updated_at বিদ্যমান)
• একটি মৌলিক নিয়ম (স্ট্যাটাস Draft থেকে সরাসরি Approved এ লাফিয়ে যেতে পারে না)

টেস্ট ডেটা ছোট ও পুনরাবৃত্তিযোগ্য রাখুন। লজিককে যা দরকার তা সেড করুন: এক জন requester, এক জন approver, এবং একটি রিকোয়েস্ট "Pending" অবস্থায়। স্থিতিশীল আইডেন্টিফায়ার (ফিক্সড ইমেইল) থাকলে রিজেনারেশন পরে একই রেকর্ড খুঁজে পাওয়া সহজ হয়।

এখন মডেল পরিবর্তনের কথা ভাবুন: আপনি একটি নতুন required ফিল্ড cost_center যোগ করলেন। অনেক স্যুট ভেঙে যায় কারণ তারা পুরনো শেপে রিকোয়েস্ট তৈরি করত।

প্রতিটি টেস্ট পুনরায় লেখা না করে, একটি শেয়ার্ড "create request" হেল্পার (বা সিড স্টেপ) আপডেট করুন যাতে cost_center অন্তর্ভুক্ত করা হয়। আপনার ওয়ার্কফ্লো টেস্টগুলো স্ট্যাটাস ট্রানজিশনেই ফোকাস রাখবে, এবং আপনার কন্ট্রাক্ট চেক নতুন required ফিল্ডটি যদি রিকোয়েস্ট বা রেসপন্স স্কিমা বদলে দেয় সেটি ধরবে।

পরবর্তী ধাপ: স্যুটটি ছোট, কাজে লাগার এবং আপ-টু-ডেট রাখুন

একটি টেস্ট স্যুট তখনই সাহায্য করে যখন মানুষ এটাকে ভরসাযোগ্য মনে করে। ভরসা মরে যায় যখন স্যুট দ্রুত বাড়ে এবং পরে পচে যায়। ছোট সেটের উপর ফোকাস রাখুন—সেই ওয়ার্কফ্লোগুলো যেগুলো প্রকৃত ব্যবসায়িক মূল্য প্রতিনিধিত্ব করে।

আপনার অগ্রাধিকারপ্রাপ্ত ওয়ার্কফ্লো তালিকাকে একটি ছোট, পুনরাবৃত্তিযোগ্য টেস্ট ব্যাকলগে পরিণত করুন। প্রতিটি ওয়ার্কফ্লোকে একটি স্পষ্ট পাস কন্ডিশন দিন যা এক বাক্যে বোঝানো যায়। যদি আপনি "ডান হয়েছে" কীভাবে বোঝাবেন তা বলতে না পারেন, টেস্টও অস্পষ্ট হবে।

অধিকাংশ টিমের জন্য একটি সাদাসিধে তাল:

• প্রতিটি চেঞ্জে ৫ থেকে ১০টি হাই-ভ্যালু ওয়ার্কফ্লো টেস্ট চালিয়ে যান।
• মৃত টেস্ট মুছে ফেলতে এবং সিড ডেটা রিফ্রেশ করতে মাসিক ক্লিনআপ করুন।
• প্রোডাকশনে পৌঁছে যাওয়া একটি বাগ ধরলে, এমন একটি টেস্ট যোগ করুন যা সেটি ধরত।
• টেস্ট ডেটা ছোট ও নামকৃত রাখুন যাতে ফেলগুলো বোঝা সহজ হয়।
• ব্যর্থতা সাপ্তাহিক রিভিউ করুন এবং টেস্ট বা ওয়ার্কফ্লো অবিলম্বে ঠিক করুন।

ক্লিনআপ একটি বাস্তব কাজ। যদি একটি ওয়ার্কফ্লো বদলে যায় এবং পুরনো টেস্ট আর বাস্তবতাকে উপস্থাপন না করে, তা তৎক্ষণাৎ মুছুন বা পুনঃলিখন করুন।

আপনি যদি AppMaster (appmaster.io) এ ওয়ার্কফ্লো এবং API তৈরি করে থাকেন, সেই একই দৃশ্যমানতা ব্যবহার করে কনক্রিট আউটকাম সংজ্ঞায়িত করুন এবং শুরুতেই কিছু ওয়ার্কফ্লো-লেভেল চেক অ্যাঙ্কর করুন। এটা প্রায়ই সবচেয়ে সহজ উপায় টেস্টগুলোকে ডেটা মডেল বিকাশের সঙ্গে লাইন্ড করে রাখার।