React, Go API এবং Flutter-এ চ্যাট-জেনারেটেড অ্যাপ পরীক্ষা করার অগ্রাধিকারভিত্তিক পরিকল্পনা—ন্যূনতম ইউনিট, ইন্টিগ্রেশন এবং E2E চেক যা বেশিরভাগ রিগ্রেশন ধরবে।
চ্যাট-জেনারেট করা কোডবেসগুলো প্রায়শই একই জায়গায় ব্যর্থ হয়, কারণ কোডটি অনেক সময় সঠিক-দেখায় এমন টুকরো থেকে জড়ো করা হয় যেগুলো একে অপরের সঙ্গে সম্মত হতে বাধ্য করা হয়নি। বেশিরভাগ ফিচার “হ্যাপি পাথ”-এ কাজ করে, কিন্তু বাস্তব ব্যবহারকারীরা দ্রুত ক্লিক করলে, অদ্ভুত ইনপুট পাঠালে, বা পুরোনো ক্লায়েন্ট ব্যবহার করলে ভেঙে পড়ে।
বহু ঝুঁকি থাকে glue কোডে: স্ক্রিনগুলোকে API কলের সাথে যুক্ত করা, API রেসপন্সকে UI স্টেট-এ ম্যাপ করা, এবং ব্যবহারকারীর ইনপুটকে ডাটাবেস লেখায় পরিণত করা—এসব ছোট ছোট অংশ। এগুলো বিরক্তিকর বলে কম মনোযোগ পায়, কিন্তু পুরো অ্যাপের ফ্লো নিয়ন্ত্রণ করে।
রিগ্রেশনগুলোও এমন বর্ডারগুলোতে ঘন হয় যেখানে দুইটি কম্পোনেন্টকে একটি কন্ট্র্যাক্ট শেয়ার করতে হয়। UI এক আকৃতি আশা করে, API অন্যটি ফেরত দেয়। API ধরে নেয় ডেটাবেস একটি মান স্বীকার করবে, তারপর কোনো কনস্ট্রেইন্ট তা প্রত্যাখ্যান করে। অথবা এক লেয়ার নামকরণ, টাইপ, বা ডিফল্ট বদলে দেয় এবং অন্যগুলো অনুসরণ করে না।
একই ত্রুটি জায়গাগুলো বার বার দেখা যায়:
গতিস্থিতি এটি আরও তীব্র করে। Koder.ai-এর মতো প্ল্যাটফর্ম দ্রুত পুনরাবৃত্তি উৎসাহিত করে: আপনি প্রম্পট দেন, পুনরায় জেনারেট করেন, রিফ্যাক্টর করেন, এবং এগিয়ে যান। এটা শক্তি—কিন্তু ছোট পরিবর্তনগুলো ঘন হয় এবং একটি বর্ডারি ভাঙার সম্ভাবনা বাড়ে। দ্রুত শিপ করলে এমন টেস্ট দরকার যেগুলো দ্রুত চলে এবং জোরে ব্যর্থ হয়।
লক্ষ্য হচ্ছে আত্মবিশ্বাস, নিখুঁত হওয়া নয়। আপনি প্রতিটি লাইনের সঠিকতা প্রমাণ করার চেষ্টা করছেন না। আপনি সেই পরিবর্তনগুলো ধরতে চাচ্ছেন যেগুলো প্রোডাকশনে লজ্জা দেয়: ফর্ম যা আর সেভ করে না, API যা বৈধ রিকোয়েস্ট রিজেক্ট করে শুরু করেছে, বা ডাটাবেস আপডেট যা নীরবে কোনো ফিল্ড লেখা বন্ধ করে দিয়েছে।
একটি সরল প্রত্যাশা সাহায্য করে: প্রথমে কন্ট্র্যাক্ট এবং শীর্ষ ব্যবহারকারী পথগুলো রক্ষা করুন। বাকিটা অপেক্ষা করতে পারে যতক্ষণ না তা প্রমান করে যে ক্ষতি হচ্ছে।
চ্যাট-জেনারেটেড কোডে সবচেয়ে বড় ঝুঁকি সাধারণত কম্পাইলেশন নয়। ঝুঁকি হলো ছোট পরিবর্তনগুলো এমন আচরণ ভাঙে যা আপনি স্পষ্ট মনে করতেন।
শুরু করুন আপনার শীর্ষ ঝুঁকিগুলো সাদাসিধে ভাষায় নাম দিয়ে। যদি কোনো বাগ এগুলোকে টেনে দেয়, তা দ্রুত ব্যয়বহুল হয়ে যায়:
তারপর সবচেয়ে ছোট টেস্ট সেট বেছে নিন যা বাস্তব ব্যবহারকারী ফ্লো এবং নিচে থাকা API কন্ট্র্যাক্টগুলো কভার করে। একটি ভাল নিয়ম: প্রতিটি কোর ফ্লো-এর জন্য একটি হ্যাপি পাথ এবং একটি “খারাপ ইনপুট” কেস। উদাহরণস্বরূপ, “আইটেম তৈরি” সফলতা এবং একটি ভ্যালিডেশন ব্যর্থতা (প্রয়োজনীয় ফিল্ড অনুপস্থিত) টেস্ট করুন — কারণ প্রম্পট বদলালে উভয়ই প্রায়ই ভেঙে যায়।
তারপর সিদ্ধান্ত নিন কোনটুকু মর্জের আগে ধরা জরুরি vs রিলিজের আগে। মर्जের আগে টেস্টগুলো দ্রুত এবং বিশ্বাসযোগ্য হওয়া উচিত। রিলিজের আগে ধীরে তবে বিস্তৃত টেস্ট চালানো যায়।
একটি সাধারণ অগ্রাধিকারের স্কেল বিতর্ক কম রাখে:
কংক্রিট উদাহরণ: React অ্যাপের “Change password” ফিচার যেখানে Go API এবং Flutter ক্লায়েন্ট আছে।
P0: API দুর্বল পাসওয়ার্ড প্রত্যাখ্যান করে, API স্টোর হ্যাশ আপডেট করে, এবং দুই ক্লায়েন্টেই ব্যর্থ হলে একটি এরর মেসেজ দেখায়।
P1: রেট লিমিটিং এবং সেশন এক্সপায়ারি।
P2: পিক্সেল-পারফেক্ট UI স্টেট।
আপনি যদি চ্যাট-জেনারেটেড অ্যাপ (Koder.ai-এর মত টুল দিয়ে নির্মিত প্রকল্পসহ) টেস্ট করে থাকেন, এই 80/20 লেন্স আপনাকে বহু দুর্বল টেস্ট এড়াতে সাহায্য করবে যা তবুও ব্যবহারকারীরা যে ব্যর্থতাগুলো অনুভব করেন সেগুলো মিস করে।
React রিগ্রেশন সাধারণত দুই জায়গা থেকে আসে: ছোট লজিক ভুল (ডেটা শেইপিং, ভ্যালিডেশন) এবং UI স্টেট যা বাস্তবতার সাথে মেলে না (লোডিং, এরর, ডিসেবল্ড বাটন)। ব্যর্থতা যেখানে ব্যবহারকারীর কাছে কষ্ট দেয় সেখান থেকেই শুরু করুন।
যদি কোনো ফাংশনের ইনপুট আর আউটপুট স্পষ্ট হয়, UI-এর আগে তা টেস্ট করুন। এই টেস্টগুলো দ্রুত, সচরাচর ফ্লেকি নয়, এবং এক লাইনের ছোট পরিবর্তন থেকে আসা বড় ভাঙনগুলো থেকে রক্ষা করে।
ভাল প্রথম টার্গেট: তারিখ ও মুদ্রা ফরম্যাটার, ফিল্ড ভ্যালিডেটর, API রেসপন্সকে ভিউ মডেলে ম্যাপ করা, এবং রিডিউসার বা স্টেট মেশিনগুলো যা স্ক্রিন চালায়।
তারপর কিছু কম্পোনেন্ট টেস্ট লিখুন সেই স্ক্রিনগুলোর জন্য যেগুলো মানুষ কাজ সম্পন্ন করতে ব্যবহার করে। বহু শ্যালো স্ন্যাপশটের পরিবর্তে কয়েকটি টেস্ট রাখুন যা ব্যবহারকারীর মতো আচরণ করে: ফর্মে টাইপ করা, একটি বাটনে ক্লিক করা, এবং ব্যবহারকারী কি দেখে তা assert করা।
সামান্য অংশগুলোতে ভাঙে এমন UI স্টেটগুলোর উপর ফোকাস করুন: ফর্ম ভ্যালিডেশন এবং সাবমিট আচরণ, ডিসেবল্ড স্টেট (ডাবল-সাবমিট প্রতিরোধসহ), লোডিং ও রিট্রাই, এরর রেন্ডারিং, এবং এ্যাম্পটি বনাম রেজাল্ট স্টেট।
যে কোনো কিছু নেটওয়ার্কের সঙ্গে কথা বলে, সেভাবে boundary-এ মক করুন। আপনার API ক্লায়েন্টকে সিম হিসেবে বিবেচনা করুন: রিকয়েস্ট শেপ assert করুন (মেথড, পাথ, মূল কুয়েরি প্যারাম, এবং পে-লোড), তারপর কম্পোনেন্টকে বাস্তবসম্মত রেসপন্স দিয়ে খাওয়ান। এটা কন্ট্র্যাক্ট ড্রিফট দ্রুত ধরবে, বিশেষত যখন ব্যাকএন্ড দ্রুত জেনারেট বা সম্পাদিত হচ্ছে।
একটি নিয়ম যা বারবার কাজে দেয়: প্রতিবার আপনি একটি বাগ ফিক্স করলে, এমন একটি টেস্ট যোগ করুন যা যদি বাগটি ফিরে আসে তখন ফেল করে। উদাহরণস্বরূপ, যদি Koder.ai-জেনারেটেড পেজ আগে userId পাঠাতো কিন্তু পরে id পাঠাতে শুরু করে, এমন একটি টেস্ট যোগ করুন যা আউটগোয়িং পে-লোডের কী-গুলো যাচাই করে।
Go হ্যান্ডলারগুলো বাইরের দিক থেকে সঠিক দেখলেও ছোট লজিক গ্যাপ লুকিয়ে রাখতে পারে যা বাস্তব বাগে পরিণত হয়। দ্রুত জিতে নেওয়ার জন্য এমন টেস্ট যা ইনপুট, অনুমতি, এবং ডেটা মিউটেশন নিয়মগুলো পিন করে রাখা উচিত।
রিকোয়েস্ট ভ্যালিডেশন দিয়ে শুরু করুন। চ্যাট-জেনারেটেড কোড কখনও খালি স্ট্রিং গ্রহন করতে পারে, ম্যাক্স লেন্থ উপেক্ষা করতে পারে, বা ভুল ডিফল্ট প্রয়োগ করতে পারে। এমন টেস্ট লিখুন যা হ্যান্ডলারকে (অথবা এর ভ্যালিডেশন ফাংশনকে) খারাপ পে-লোড দিয়ে কল করে এবং পরিষ্কার 400 রেসপন্স এবং ব্যবহারযোগ্য এরর assert করে।
তারপর এজে auth এবং পারমিশন লকডাউন করুন। সাধারণ রিগ্রেশন হলো “auth আছে, কিন্তু ভুল রোল আপডেট করতে পারে।” হ্যাপি পাথ এবং কয়েকটি ফরবিডেন কেস টেস্ট করুন, ইউজার কনটেক্সট তৈরি করে হ্যান্ডলার বা মিডলওয়্যার কল করে।
তারপর ব্যবসায়িক নিয়মগুলোতে ফোকাস করুন যা ডেটা মিউটেট করে। Create, update, delete, এবং যেকোনও idempotent endpoint (যেমন “create if not exists”) টাইট টেস্ট প্রাপ্য। এসব জায়গায় ছোট রিফ্যাক্টর ডুপ্লিকেট তৈরি করতে পারে, প্রয়োজনীয় স্টেট ট্রানজিশন বাদ দিতে পারে, বা immutable ফিল্ডগুলো ওভাররাইট করতে পারে।
এরর ম্যাপিং স্পষ্ট করুন। আপনার API সাধারণ ব্যর্থতাগুলোকে সঠিক স্ট্যাটাস কোডে রূপান্তর করা উচিত: খারাপ ইনপুট (400), না পাওয়া (404), কনফ্লিক্ট (409), এবং অপ্রত্যাশিত এরর (500)। ইউনিট টেস্টগুলো স্ট্যাটাস এবং স্থির এরর শেপ উভয়ই assert করা উচিত যাতে ক্লায়েন্ট ভাঙে না।
শুরুতেই কভার করার উচ্চ-ROI চেক: প্রয়োজনীয় ফিল্ড ও ডিফল্ট, রোল-ভিত্তিক পারমিশন চেক, idempotency, এবং সাধারণ ব্যর্থতার মধ্যে পরিষ্কার ম্যাপিং।
টেবল-ড্রিভেন টেস্ট এজ কেসগুলোকে পাঠযোগ্য রাখে:
tests := []struct{
name string
body string
wantStatus int
}{
{"missing name", `{"name":""}`, 400},
{"too long", `{"name":"aaaaaaaaaaaaaaaa"}`, 400},
}
Flutter বাগগুলো সাধারণত ছোট ক্লায়েন্ট-সাইড অনুমানের কারণে ঘটে: কোনো ফিল্ড কখনো null হতে পারে, কোনো তারিখ ভিন্ন ফরম্যাটে আসতে পারে, বা একটি স্ক্রিন রিট্রাইয়ের পরে লোডিং-এ আটকে যায়। কয়েকটি ফোকাসড টেস্ট এইগুলো অধিকাংশ সময়ে ধরতে পারে আগে যে সাপোর্ট টিকিট হয়।
ডেটা ম্যাপিং দিয়ে শুরু করুন। সবচেয়ে বড় ঝুঁকি JSON এবং আপনার Dart মডেলের সীমান্ত। বাস্তবসম্মত পে-লোড fromJson-এ খাওয়ান এবং নিশ্চিত করুন আপনি অনুপস্থিত ফিল্ড, পুনঃনামকৃত কী, এবং অদ্ভুত মান হ্যান্ডেল করেন। Enum ও তারিখ সাধারণভাবে সমস্যার কারণ: নতুন enum ভ্যালু অ্যাপ ভেঙে ফেললে চলবে না, পার্সিং সেফলি ব্যর্থ করা উচিত (স্পষ্ট এরর সহ) নীরবে ভুল মান উত্পাদন করার পরিবর্তে।
পরের ধাপে স্টেট ট্রানজিশন টেস্ট করুন। আপনি BLoC, Provider, Riverpod, বা সহজ setState যাই ব্যবহার করুন না কেন, প্রতিদিন যে স্টেপগুলো ব্যবহারকারীরা দেখে সেগুলো লক করুন: প্রথম লোড, রিফ্রেশ, এরর, এবং রিট্রাই। এই টেস্টগুলো কিফায়তী এবং “চিরন্তন স্পিন” সমস্যা দ্রুত ধরবে।
একটি সংক্ষিপ্ত সেট যা সাধারণত ভালো রিটার্ন দেয়:
কংক্রিট উদাহরণ: Koder.ai দিয়ে তৈরি “Create Project” স্ক্রিন যদি প্রজেক্ট নাম ও রিজিওন নেয়। ইউনিট-টেস্ট করুন যে খালি নাম ব্লক হয়, হোয়াইটস্পেস ট্রিম হয়, এবং API থেকে আগত আগে অচেনা region ভ্যালু ড্রপডাউন ক্র্যাশ না করে।
গোল্ডেন UI টেস্ট সাহায্য করতে পারে, কিন্তু সেগুলো বিরল রাখুন। কেবল কয়েকটি স্থিতিশীল স্ক্রিনের জন্য ব্যবহার করুন যেখানে লেআউট রিগ্রেশন সত্যিই কষ্ট দেয়, যেমন লগইন স্ক্রিন, একটি প্রধান ড্যাশবোর্ড, বা একটি ক্রিটিক্যাল চেকআউট/ক্রিয়েট ফ্লো।
আপনি যদি চ্যাট টুল দিয়ে দ্রুত বানান, সবচেয়ে কষ্টদায়ক বাগগুলো লেয়ারগুলোর মধ্যেই দেখা যায়: React পেজ একটি API ডাকে, Go হ্যান্ডলার Postgres-এ লিখে, তারপর UI একটি রেসপন্স শেপ ধরে নেয় যা বদলে গেছে। ইন্টিগ্রেশন টেস্টগুলো ক্রস-লেয়ার ভাঙন ধরার দ্রুত উপায়, সবকিছু পরীক্ষা করার চেষ্টা না করে।
একটি ভাল নিয়ম: প্রতিটি কোর রিসোর্সের জন্য একটা বাস্তব Postgres-ব্যাকড পাথ end-to-end টেস্ট করুন। সব এজ কেস নয়—শুধু এক হ্যাপি পাথ যা ওয়্যারিং কাজ করছে কি না প্রমাণ করে।
শুরুতে কয়েকটি উচ্চ-সিগন্যাল চেক:
এই টেস্টগুলোর জন্য বাস্তব Postgres ইনস্ট্যান্স ব্যবহার করুন (সাধারণত ডিসপোজেবল ডাটাবেস)। যা দরকার শুধু সেগুলো সিড করুন, প্রতিটি টেস্টের পরে ক্লিন আপ করুন, এবং assertionsগুলো ব্যবহারকারীরা লক্ষ্য করে এমন জিনিসে সীমাবদ্ধ রাখুন: সেভ করা ডেটা সঠিক, পারমিশন কার্যকর, এবং ক্লায়েন্টরা রেসপন্স পার্স করতে পারে।
উদাহরণ: “Create Project” ফিচার। Go ইন্টিগ্রেশন টেস্ট POST /projects এ হিট করে, 201 রেসপন্স চেক করে, তারপর প্রজেক্ট ফেচ করে নিশ্চিত করে নাম এবং owner ID সঠিক। React ইন্টিগ্রেশন টেস্ট ক্রিয়েট ফর্ম সাবমিট করে এবং সাকসেস স্টেটে নতুন নাম দেখা যাচ্ছেত কিনা নিশ্চিত করে। Flutter টেস্ট প্রজেক্ট লিস্ট খুলে, প্রকল্প তৈরি করে, এবং রিফ্রেশের পরে তা দেখা যায় কি না নিশ্চিত করে।
যদি আপনি Koder.ai-এ অ্যাপ জেনারেট করেন, এই টেস্টগুলো জেনারেট করা UI বা হ্যান্ডলার যদি অনিচ্ছাকৃতভাবে পে-লোড শেপ বা এরর ফরম্যাট বদলে দেয় তখনও আপনাকে রক্ষা করবে।
E2E টেস্ট হলো “অ্যাপ কি end-to-end কাজ করছে?”–এর সেফটি নেট। সেগুলো সবচেয়ে মূল্যবান যখন ছোট এবং নিরস থাকবে: স্মোক টেস্ট যা React, Go API, Postgres এবং Flutter ক্লায়েন্টের মধ্যে ওয়্যারিং এখনও কাজ করছে সেটা প্রমাণ করে।
শুধু কয়েকটি জার্নি বেছে নিন যেগুলো ভাঙলে বাস্তবে অর্থ বা বিঘ্ন ঘটে: সাইন ইন/আউট, একটি রেকর্ড তৈরি করা, সম্পাদনা ও সেভ করা, সার্চ/ফিল্টার ও রেজাল্ট খোলা, এবং যদি থাকে তাহলে চেকআউট/পেমেন্ট।
প্রথমে একটি ব্রাউজার ও একটি ডিভাইস প্রোফাইলেই চালান (উদাহরণ: ওয়েবের জন্য Chrome এবং মোবাইলের জন্য একটি সাধারণ ফোন সাইজ)। গ্রাহকরা যখন প্রকৃত ইস্যু রিপোর্ট করবে তখনই আরও ব্রাউজার/ডিভাইসে বাড়ান।
স্থিতিশীলতা একটি ফিচার। টেস্টগুলো детারমিনিস্টিক করুন যাতে কেবল সত্যিই ভাঙলে তারা ফেল করে:
E2E-কে প্রধান পাথ যাচাই করতে ব্যবহার করুন, সব এজ কেস নয়। এজ কেসগুলো ইউনিট এবং ইন্টিগ্রেশন টেস্টে রাখা ভালো যেখানে সেগুলো সস্তা এবং কম ফ্লেকি।
টাইম নষ্ট করার দ্রুততম উপায় হলো এমন টেস্ট লেখা যা পুরুতর দেখায় কিন্তু বাস্তবে বিরল বাগই ধরেন। একটি ছোট, ফোকাসড সেট বিস্তৃত কিন্তু অবিশ্বাস্য স্যুটের চেয়ে বেশি কার্যকর।
স্ন্যাপশট টেস্টগুলি React ও Flutter-এ প্রচলিত ফাঁদ। বড় স্ন্যাপশট নিরীহ কারণে বদলে যায় (কপি টুইক, লেআউট শিফট, ছোট রিফ্যাক্টর), তাই দলগুলো হয় শব্দে ভরা আপডেট গ্রহণ করে বা ব্যর্থতা দেখে দেখেই বন্ধ হয়ে যায়। স্ন্যাপশটগুলো কেবল খুব ছোট, স্থিতিশীল সারফেসের জন্য রাখুন, যেমন একটি ছোট ফরম্যাটারের আউটপুট, পুরো স্ক্রীন নয়।
আরেকটি সহজ বাদ: থার্ড-পার্টি লাইব্রেরি টেস্ট করা। আপনাকে প্রমাণ করতে হবে না React Router, একটি ডেট পিকার, বা HTTP ক্লায়েন্ট কাজ করে। পরিবর্তে আপনার ইন্টিগ্রেশন পয়েন্ট টেস্ট করুন: আপনি যেখানে সেটআপ করেন, ডেটা সেখানে ম্যাপ করেন, বা এর এরর হ্যান্ডেল করেন।
স্টাইলিং টেস্ট সাধারণত মূল্যবান নয়। আচরণগত চেক (ফর্ম অবৈধ হলে বাটন ডিসেবল, 401-এ এরর মেসেজ দেখানো) পিক্সেল-লেভেল assertions-এর চেয়ে ভাল। ব্যতিক্রম করুন যখন স্টাইলিং আচরণ বা সম্মতি প্রভাবিত করে: কনট্রাস্ট চাহিদা, কীবোর্ড ব্যবহারকারীর জন্য ফোকাস আউটলাইন, বা এমন একটি রেস্পন্সিভ লেআউট যা পরিবর্তিত হলে ব্যবহারকারীর কাজ পরিবর্তিত হয়।
একই চেককে প্রতিটি লেয়ারে পুনরাবৃত্তি করা এড়ান। যদি আপনি ইতোমধ্যে Go API ইন্টিগ্রেশন টেস্টে নিশ্চিত করেন যে অননুমোদিত রিকোয়েস্ট 401 ফেরত দেয়, আপনি সম্ভবত একই assertion ইউনিট টেস্ট ও E2E-তে পুনরাবৃত্তি করতে হবে না।
পারফরম্যান্স টেস্ট করা মূল্যবান, শুধু পরে করুন। আপনার অ্যাপ ফ্লো স্থিতিশীল হওয়ার পরে (উদাহরণস্বরূপ, Koder.ai-জেনারেটেড ফিচার প্রতিদিন পরিবর্তিত না হলে) এক বা দুইটি পরিমাপযোগ্য লক্ষ্য সেট করুন এবং ধারাবাহিকভাবে ট্র্যাক করুন।
ধরা যাক আপনি একটি সাদামাটা ফিচার দেয়: সাইন-ইন করা ইউজার তার প্রোফাইল সম্পাদনা করে এবং ইমেল পরিবর্তন করে। এটি একটি ভালো ক্যানারি কারণ এটি UI স্টেট, API নিয়ম, এবং ক্লায়েন্ট ক্যাশিং স্পর্শ করে।
এটা যে ন্যূনতম টেস্ট সেটটি সাধারণত বেশিরভাগ রিগ্রেশন ধরবে তা নিম্নরূপ:
updated_at পরিবর্তন হয়) তা টেস্ট করুন।এই সেটটি সাধারণ ব্রেকপয়েন্টগুলোকে লক্ষ্য করে: React-এ UI ভ্যালিডেশন ও ডিসেবল্ড স্টেট, Go-তে নিয়ম ড্রিফট, এবং Flutter-এ স্টেল বা বিভ্রান্তিকর UI। যদি আপনি Koder.ai-এর মতো প্ল্যাটফর্মে তৈরি করেন যেখানে কোড দ্রুত লেয়ার জুড়ে বদলে যেতে পারে, এই টেস্টগুলো আপনাকে দ্রুত সিগন্যাল দেয় কম রক্ষণাবেক্ষণের সাথে।
সেট টাইমার 60 মিনিটে এবং ঝুঁকির উপরে ফোকাস করুন, নিখুঁততায় নয়। চ্যাট-জেনারেটেড কোড সঠিক দেখলেও ছোট নিয়ম, এজ কেস, বা লেয়ারগুলোর মধ্যে ওয়্যারিং মিস করতে পারে। আপনার লক্ষ্য একটি সংক্ষিপ্ত টেস্ট সেট যা আচমকা পরিবর্তনে জোরে ফেল করে।
আপনি যে 5টি ইউজার অ্যাকশন প্রতিবার কাজ করা উচিত সেগুলো লিখুন। নির্দিষ্ট রাখুন: “sign in”, “create an order”, “pay”, “see order history”, “reset password”。Koder.ai-এ নির্মাণ করলে আজ আপনি যা ডেমো করতে পারেন সেই পথগুলো বেছে নিন, ভবিষ্যতে যা যোগ করবেন না।
প্রতি ফ্লোয়ের জন্য এমন একটি নিয়ম খুঁজুন যা ভুল হলে বাস্তবে ক্ষতি হবে। প্রতিটি লেয়ারে একটি দ্রুত ইউনিট টেস্ট যোগ করুন যেখানে সেই নিয়ম বসে:\n\n- React: ভ্যালিডেশন, ফরম্যাটিং, শর্তানুগ UI স্টেট (লোডিং, খালি, এরর)\n- Go API: ব্যবসায়িক নিয়ম, পারমিশন চেক, ইনপুট এজ কেস\n- Flutter: ক্লায়েন্ট-সাইড ম্যাপিং, স্টেট ট্রানজিশন, রিট্রাই ও অফলাইন হ্যান্ডলিং
উদাহরণ: “Checkout কখনই নেগেটিভ কৌশক পরিমাণ অনুমোদন করা উচিত নয়।” একবার API-তে টেস্ট করুন, যদি UI/ক্লায়েন্টেও এ নীতিটি প্রয়োগ করা হয় তবে সেখানে একটি টেস্ট যোগ করুন।
প্রতি ফ্লো একটি ইন্টিগ্রেশন টেস্ট যোগ করুন যা বাস্তব API-তে হিট করে এবং Postgres-এ একটি বাস্তব ডাটাবেস লেখে। এটিকে সরু রাখুন: তৈরি, আপডেট, ফেচ, এবং স্টোর করা রেজাল্ট ভেরিফাই করুন। এটা ওয়্যারিং ভুল ধরবে—ভুল ফিল্ড নাম, মিসিং ট্রানজেকশন, বা ভাঙা মাইগ্রেশন ইত্যাদি।
মোট 3–6টি E2E ফ্লো বেছে নিন। সর্বোচ্চ ক্রস-লেয়ার পথগুলোকে অগ্রাধিকার দিন (login → create → view)। স্থিতিশীল টেস্ট ডেটা নির্ধারণ করুন (সিডড ইউজার, পরিচিত ID, স্থির ঘড়ি) যাতে টেস্ট র্যান্ডমনেসে নির্ভর না করে।
CI-তে এই অর্ডারে টেস্ট চালান: প্রতিটি পুশে ইউনিট টেস্ট, পুশ বা main-এ ইন্টিগ্রেশন টেস্ট, এবং main বা নাইটলি-তে E2E।
সবচেয়ে দ্রুত সময় নষ্ট করার উপায় হলো ভুল লেভেলে ভুল জিনিস টেস্ট করা। বেশিরভাগ ব্যর্থতা পূর্বানুমানযোগ্য: অস্পষ্ট কন্ট্র্যাক্ট, বাস্তবসম্মত না এমন মক, এবং এমন একটি স্যুট যা কেউ বিশ্বাস করে না।
একটি সাধারণ ভুল হল টেস্ট শুরু করা API কন্ট্র্যাক্ট নিয়ে একমত না হয়ে। যদি Go API এরর কোড, ফিল্ড নাম, বা pagination নিয়ম বদলে দেয়, React ও Flutter ক্লায়েন্ট যেভাবে ব্যর্থ হবে তা অপ্রত্যাশিত দেখাবে। আগে কন্ট্র্যাক্ট লিখে রাখুন (রিকোয়েস্ট, রেসপন্স, স্ট্যাটাস কোড, এরর শেপ), তারপর কিছু ইন্টিগ্রেশন টেস্ট দিয়ে এটি লক করুন।
আরেকটি ফাঁদ হলো মকও বেশি ব্যবহার করা। মকগুলো যদি Postgres, auth মিডলওয়্যার, বা বাস্তব নেটওয়ার্ক রেসপন্সের মত আচরণ না করে, তাহলে মিথ্যা নিরাপত্তা বোধ তৈরি করে। খাঁটি লজিকের জন্য ইউনিট টেস্ট ব্যবহার করুন, কিন্তু যে কিছু প্রক্রিয়ার সীমানা পার করে—সেগুলোর জন্য পাতলা ইন্টিগ্রেশন টেস্ট পছন্দ করুন।
একটি তৃতীয় ভুল হলো সবকিছুর জন্য E2E-এ নির্ভর করা। E2E ধীর এবং ফ্লেকি, তাই কেবল সর্বোচ্চ মূল্যবান ইউজার জার্নিকে রক্ষা করা উচিত। বেশিরভাগ কভারেজ ইউনিট এবং ইন্টিগ্রেশন টেস্টে রাখুন যেখানে ব্যর্থতাগুলো ডায়াগনোস করা সহজ।
অবশেষে, ফ্লেকিনেস উপেক্ষা করবেন না। যদি টেস্ট কখনও কখনও ব্যর্থ হয়, দলটি শুনা বন্ধ করে দেয়। ফ্লেকি টেস্টগুলো ডেলিভারি পাইপলাইনে বাগ হিসেবে বিবেচনা করুন এবং দ্রুত ঠিক করুন।
একটি দ্রুত চেকলিস্ট টেস্ট বাড়ানোর আগে:
পরবর্তী ধাপ: পরিকল্পনা বাস্তবায়ন করুন, লেয়ার অনুসারে রিগ্রেশন ট্র্যাক করুন, এবং সচেতনভাবে স্যুটকে ছোট রাখুন। যদি আপনি Koder.ai দিয়ে তৈরি করে থাকেন, জেনারেট করা API কন্ট্র্যাক্ট কনফার্ম করার পরে সঙ্গে সঙ্গে টেস্ট যোগ করা ভাল।
যদি আপনি Koder.ai-এর মাধ্যমে জেনারেট করা অ্যাপ নিয়ে কাজ করে থাকেন এবং ওয়েব, ব্যাকএন্ড, ও মোবাইলে এক জায়গায় ইটারেট করতে চান, Koder.ai প্ল্যাটফর্ম সেই ওয়ার্কফ্লোর চারপাশে ডিজাইন করা হয়েছে। যে টুলই ব্যবহার করুন না কেন, টেস্টিং পদ্ধতিটি একই থাকে: কন্ট্র্যাক্ট লক করুন, মূল পথগুলো কভার করুন, এবং স্যুটটি এতই বিরস রাখুন যে আপনি আসলেই সেটি চালাবেন।
তারা প্রায়ই সীমান্তে ব্যর্থ হয়: UI ↔ API ↔ ডেটাবেস। জেনারেট করা টুকরোগুলো আলাদাভাবে সঠিক দেখালেও ছোট কন্ট্র্যাক্ট মিসম্যাচ (ফিল্ড নেম, টাইপ, ডিফল্ট, স্ট্যাটাস কোড) বাস্তব ব্যবহারকারীদের ‘গন্ডগোল’ ইনপুট, ডাবল-ক্লিক বা পুরনো ক্লায়েন্ট ব্যবহারে সামনে আসে।
গ্লু ফাংশনগুলোতেই শুরু করুন: প্রধান ইউজার ফ্লো এবং তাদের নিচে থাকা API কন্ট্র্যাক্টগুলো। সাধারণত “create/update + validate + save + read back” মতো ছোট সেটগুলো অনেক বেশি বাস্তব বাগ ধরে ফেলবে তুলনায় বহু UI স্ন্যাপশটের।
ব্যয়বহুল ঝুঁকিগুলো নিয়ে শুরু করুন:\n\n- অর্থ সংক্রান্ত ফ্লো (প্রাইসিং, ক্রেডিট, বিলিং, মিটারিং)\n- পারমিশন (কে কি দেখতে/পরিবর্তন করতে পারে)\n- ডেটা লস (ডিলিট, ওভাররাইট, মাইগ্রেশন)\n- উপলভ্যতা (লগইন ও কোর API এন্ডপয়েন্ট)\n\nতারপর সবচেয়ে ছোট টেস্টগুলো লিখুন যা এই গুলো নীরবভাবে বিচ্যুত হতে পারে না। এইভাবে বিতর্ক বন্ধ থাকে: প্রথম ঝুঁকিগুলোকে শ্রেণীবদ্ধ করুন এবং সেই অনুযায়ী P0/P1/P2 নির্ধারণ করুন।
সহজ সিঁড়ি ব্যবহার করুন:\n\n- P0: ব্যর্থ হলে মর্জ ব্লক করে (কোর ফ্লো, কন্ট্র্যাক্ট, auth, ডেটা লিখন)\n- P1: CI-তে চলে; এক দিনের মধ্যে ঠিক করুন (রেট লিমিট, সেশন এক্সপায়ারি, রিট্রাই)\n- P2: নির্ধারিত সময়ে বা রিফ্যাক্টরিং-এ চালান (অতিরিক্ত UI পলিশ, বিরল এজ কেস)\n\nপ্রথমে ক্যাটেগরি ঠিক করুন, তারপর টেস্ট লিখুন।
শুরুতে খাঁটি লজিকের টেস্টগুলি (ফরম্যাটার, ভ্যালিডেটর, API-ответ→ভিউ মডেল ম্যাপিং, রিডিউসার/স্টেট মেশিন) করুন। এরপর কয়েকটি কনটেক্সট-ভিত্তিক কম্পোনেন্ট টেস্ট লিখুন যা ব্যবহারকারীর মতো আচরণ করে:\n\n- সাবমিট সাকসেস\n- ভ্যালিডেশন ফেইলিওর\n- লোডিং → সাকসেস\n- লোডিং → এরর → রিট্রাই\n\nনেটওয়ার্কের সঙ্গে যেগুলো কথা বলে সেগুলোতে boundary-তে মক করুন: ক্লায়েন্ট API ক্লায়েন্টকে সিম হিসাবে নিয়ে রিকোয়েস্ট শেপ assertions করুন যাতে কন্ট্র্যাক্ট ড্রিফট ধরতে পারে।
চারটি জিনিস পিন করুন:\n\n- রিকোয়েস্ট ভ্যালিডেশন (মানহীন পে-লোড → 400 এবং স্পষ্ট এরর)\n- auth এবং রোল চেক (অননুমোদিত বনাম ফরবিডেন আচরণ)\n- ব্যবসায়িক নিয়ম যেগুলো ডেটা পরিবর্তন করে (create/update/delete, idempotency)\n- এরর ম্যাপিং (400/404/409/500 এবং স্থিতিশীল এরর শেপ)\n\nটেস্টগুলো টেবল-ড্রিভেন রাখুন যাতে এজ কেস যোগ করা সহজ হয়।
JSON → মডেল সীমান্ত এবং স্টেট ট্রানজিশনে ফোকাস করুন:\n\n- fromJson অনুপস্থিত/nullable ফিল্ডগুলোকে ক্র্যাশ করাবে না\n- অজানা enum ভ্যালু নিরাপদে হ্যান্ডেল হবে (বা একটি “unknown” কেসে ম্যাপ হবে)\n- তারিখ/নাম্বার পার্সিং প্রত্যাশিতভাবে কাজ করবে\n- ভিউ-মডেল বা BLoC ট্রানজিশন: লোডিং → সাকসেস, লোডিং → এরর, এরর → রিট্রাই → সাকসেস\n\nঅতিরিক্তভাবে একটি টেস্ট যোগ করুন যা নিশ্চিত করে সার্ভার থেকে ভ্যালিডেশন এরর এলে ব্যবহারকারীকে বন্ধুভাবাপন্ন মেসেজ দেখায়।
ক্রস-লেয়ার ব্রেক ধরার জন্য এগুলো কর্যকর:\n\n- প্রতিটি কোর রিসোর্সের জন্য একটি বাস্তব DB-ব্যাকড পাথ (HTTP দিয়ে লিখুন, পরে stored ফিল্ড ভ্যারিফাই করুন)\n- অauth ইন্টিগ্রেশন: টোকেন পার্সিং, রোল চেক, 401 বনাম 403\n- সবচেয়ে ব্যবহৃত এন্ডপয়েন্টগুলোর কন্ট্র্যাক্ট স্থিতিশীল রাখা (রিকোয়েস্ট/রেসপন্স শেপ)\n\nপ্রতিটি টেস্টকে এক সিচুয়েশনে সীমাবদ্ধ রাখুন এবং মিনিমাল সিড ডেটা ব্যবহার করুন যাতে স্থিতিশীল থাকে।
ওগুলোকে ছোট ও বিরস রাখুন:\n\n- সাইন ইন/আউট নিশ্চিত করা\n- একটি রেকর্ড তৈরি করুন, রিফ্রেশ করে দেখুন এটি আছে\n- সম্পাদনা করে সেভ করুন\n- সার্চ/ফিল্টার এবং রেজাল্ট খোলা\n- যদি থাকে, তাহলে চেকআউট/পেমেন্ট ফ্লো\n\nস্থায়ীত্বের জন্য: ফিক্সড টেস্ট অ্যাকাউন্ট, সিডড ডেটা, নির্দিষ্ট সিগন্যালের উপর অপেক্ষা (রেন্ডম স্লিপ নয়), প্রত্যেক রান থেকে স্টেট রিসেট।
এগুলো সাধারণত ফ্রি বা ডুপ্লিকেট নৈবচার্য থেকে বিরত থাকুন:\n\n- বড় স্ক্রীন স্ন্যাপশট (চুপচাপ পরিবর্তনগুলো অনেক আপডেট নেবে)\n- থার্ড-পার্টি লাইব্রেরি সরাসরি টেস্ট করা (আপনার ইন্টিগ্রেশন পয়েন্ট টেস্ট করুন)\n- পিক্সেল-পর্যায় স্টাইলিং টেস্ট (ব্যবহারিক যাচাই করুন)\n- একই auth/401 assertion প্রতিটি লেয়ারে পুনরাবৃত্তি করা\n\nএকটি বাস্তব বাগ ফিক্স করলে নতুন টেস্ট যোগ করুন—এইভাবে আপনার সুইট বাস্তব সমস্যা থেকেই বাড়বে।