টেস্ট অটোমেশন পিরামিড
এই পাঠে যা শিখবেন
- টেস্ট অটোমেশন পিরামিডের তিনটি স্তর এবং প্রতিটির বৈশিষ্ট্য (গতি, বিচ্ছিন্নতা, ভঙ্গুরতা)
- কেন এই নির্দিষ্ট অনুপাত (নিচে বেশি, উপরে কম) — একটি সত্যিকারের সময়ের হিসাব দিয়ে
- এই সাধারণ মডেল কীভাবে ওয়েব ও মোবাইল কোর্সের নির্দিষ্ট পিরামিড পাঠের সাথে সম্পর্কিত
- Python দিয়ে পিরামিড-আকৃতির বনাম উল্টানো স্যুটের মোট সময়ের সত্যিকারের গণনা
১ · তিনটি স্তর
একটি স্বাস্থ্যকর অটোমেটেড টেস্ট স্যুট তিনটি স্তরে ভাগ করা যায়, প্রতিটির নিজস্ব গতি ও পরিধি আছে।
একটি একক ফাংশন/মেথড, সম্পূর্ণ বিচ্ছিন্নভাবে (M3-M4)। মিলিসেকেন্ডে চলে, নেটওয়ার্ক/ডাটাবেস লাগে না। সংখ্যায় সবচেয়ে বেশি হওয়া উচিত।
একাধিক কম্পোনেন্ট একসাথে (M5) — যেমন সার্ভিস + ডাটাবেস। ইউনিট টেস্টের চেয়ে ধীর, সংখ্যায় মাঝারি।
পুরো সিস্টেম, ব্যবহারকারীর দৃষ্টিকোণ থেকে (M5/L21)। সবচেয়ে ধীর, সবচেয়ে "বাস্তবতার কাছাকাছি", কিন্তু নেটওয়ার্ক/UI টাইমিং-এর কারণে সবচেয়ে ভঙ্গুর (M7/L30-এ ফ্লেকি টেস্ট আলোচনা)। সংখ্যায় সবচেয়ে কম হওয়া উচিত।
এই পাঠটি টেস্ট অটোমেশন পিরামিডের সাধারণ, স্ট্যাক-নিরপেক্ষ সংস্করণ — যেকোনো ভাষা বা প্ল্যাটফর্মে প্রযোজ্য। Full-Stack Web Frameworks কোর্সের L47 ঠিক এই একই পিরামিডকে একটি ওয়েব অ্যাপের স্তরে (কম্পোনেন্ট, API, ব্রাউজার E2E) প্রয়োগ করে দেখায়, আর Mobile App Development কোর্সের L50 একই ধারণা মোবাইল অ্যাপের স্তরে (ভিউমডেল, সার্ভিস, UI অটোমেশন) প্রয়োগ করে দেখায় — দুটোই এই পাঠের ধারণার নির্দিষ্ট প্রয়োগ, পুনরাবৃত্তি নয়।
২ · কেন এই আকৃতি — গাণিতিক যুক্তি
নিচের কোড সেলে দুটি কাল্পনিক স্যুট তুলনা করা হয়েছে — দুটোতেই মোট ১৫০টি টেস্ট আছে, এবং প্রতিটি ধরনের টেস্টের প্রতি-টেস্ট সময় দুটো স্যুটেই একদম একই। পার্থক্য শুধু অনুপাতে — একটি স্যুট পিরামিড-আকৃতির (বেশি ইউনিট, কম E2E), আরেকটি ঠিক উল্টো (কম ইউনিট, বেশি E2E)।
# প্রতি-টেস্ট গড় সময় (মিলিসেকেন্ড) — দুটো স্যুটেই একই মান ব্যবহার হবে
COST_MS = {"unit": 1, "integration": 25, "e2e": 300}
# স্যুট ১: স্বাস্থ্যকর পিরামিড (বেশি ইউনিট, কম E2E)
pyramid_counts = {"unit": 120, "integration": 25, "e2e": 5}
# স্যুট ২: উল্টানো পিরামিড — একই মোট টেস্ট সংখ্যা, একই প্রতি-টেস্ট সময়, শুধু অনুপাত উল্টানো
inverted_counts = {"unit": 5, "integration": 25, "e2e": 120}
def total_time_ms(counts, cost):
return sum(counts[kind] * cost[kind] for kind in cost)
def report(label, counts):
total = sum(counts.values())
time_ms = total_time_ms(counts, COST_MS)
print(f"{label}: মোট {total}টি টেস্ট")
for kind in COST_MS:
n = counts[kind]
t = n * COST_MS[kind]
print(f" {kind:11s}: {n:3d}টি × {COST_MS[kind]:3d}ms = {t:6d}ms")
print(f" মোট সময়: {time_ms}ms\n")
return time_ms
pyramid_time = report("পিরামিড স্যুট", pyramid_counts)
inverted_time = report("উল্টানো স্যুট", inverted_counts)
speedup = inverted_time / pyramid_time
print(f"একই {sum(pyramid_counts.values())}টি টেস্ট, একই প্রতি-টেস্ট সময় — তবু উল্টানো স্যুট "
f"পিরামিড স্যুটের চেয়ে {speedup:.1f}× বেশি সময় নেয়।")টেস্ট অটোমেশন পিরামিড বলছে — দ্রুত, বিচ্ছিন্ন, স্থিতিশীল ইউনিট টেস্টে বেশি বিনিয়োগ করুন; ধীর, ভঙ্গুর, ব্যয়বহুল E2E টেস্ট শুধু সবচেয়ে গুরুত্বপূর্ণ ব্যবহারকারী-জার্নির জন্য সীমিত রাখুন। এই অনুপাত ভুল হলে (উল্টানো পিরামিড) স্যুট এত ধীর হয়ে যায় যে দল ঘন ঘন টেস্ট চালানো বন্ধ করে দেয় — যা টেস্টিং-এর পুরো উদ্দেশ্যকেই ব্যর্থ করে দেয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ ইউনিট টেস্ট এত দ্রুত ও সস্তা হলে, শুধু ইউনিট টেস্টই বা লিখলে সমস্যা কী? ইন্টিগ্রেশন বা E2E টেস্টের কী দরকার?
একটি ইউনিট টেস্ট প্রমাণ করে একটি মডিউল বিচ্ছিন্নভাবে সঠিক আচরণ করছে — কিন্তু প্রমাণ করে না যে সেই মডিউলগুলো একসাথে জোড়া লাগলে সঠিকভাবে কাজ করবে (M5/L19-এ বিস্তারিত — দুটো নিখুঁত মডিউলও ভুল ইন্টারফেসে জোড়া লাগলে ব্যর্থ হতে পারে)। ইন্টিগ্রেশন টেস্ট সেই জোড়া লাগানোর অংশ যাচাই করে, আর E2E টেস্ট নিশ্চিত করে পুরো সিস্টেম ব্যবহারকারীর দৃষ্টিকোণ থেকে বাস্তবেই কাজ করছে — প্রতিটি স্তর ভিন্ন ধরনের বাগ ধরে।
প্র ০২ উপরের কোড সেলে যদি "পিরামিড" স্যুটে E2E টেস্ট সংখ্যা ৫ থেকে বাড়িয়ে ১০ করা হয় (বাকি সব অপরিবর্তিত), মোট সময়ের উপর তার প্রভাব আনুমানিক কতটা হবে?
অতিরিক্ত ৫টি E2E টেস্ট × ৩০০ms = অতিরিক্ত ১,৫০০ms যোগ হবে, অর্থাৎ নতুন মোট সময় প্রায় ৩,৭৪৫ms — মূল ২,২৪৫ms-এর তুলনায় প্রায় ৬৭% বেশি, শুধু ৫টি নতুন টেস্ট যোগ করেই। এটি দেখায় কেন E2E স্তরে টেস্ট সংখ্যা সামান্য বাড়লেই মোট সময়ে তার প্রভাব দ্রুত ও অসামঞ্জস্যপূর্ণভাবে বেড়ে যায় — প্রতিটি E2E টেস্টের "সময়-মূল্য" একটি ইউনিট টেস্টের ৩০০ গুণ।
প্র ০৩ Full-Stack Web Frameworks ও Mobile App Development কোর্সের পিরামিড পাঠগুলো এই পাঠের সাথে কীভাবে সম্পর্কিত — সেগুলো কি এই পাঠের পুনরাবৃত্তি?
না। এই পাঠ পিরামিডের সাধারণ, স্ট্যাক-নিরপেক্ষ যুক্তি (গতি বনাম বাস্তবতার ট্রেড-অফ, এবং তার গাণিতিক ফল) ব্যাখ্যা করে। ওই দুটো কোর্স একই যুক্তিকে একটি নির্দিষ্ট প্রযুক্তিগত প্রেক্ষাপটে প্রয়োগ করে দেখায় — যেমন একটি ওয়েব অ্যাপে ঠিক কোন স্তরে কম্পোনেন্ট টেস্ট বসে, বা একটি মোবাইল অ্যাপে ভিউমডেল টেস্ট বনাম UI অটোমেশন কোথায় বসে। ভিত্তিগত ধারণা এক, প্রয়োগের প্রেক্ষাপট আলাদা।
অনুশীলন
-
চিন্তা করুন: একটি টিম CI পাইপলাইনে প্রতিটি কমিটে টেস্ট স্যুট চালাতে চায় এবং প্রতিটি রান
৫ সেকেন্ডের নিচে রাখতে চায়। উপরের কোড সেলের প্রতি-টেস্ট খরচ ধরে নিলে, তাদের E2E টেস্ট সংখ্যা মোটামুটি কত
সীমার মধ্যে রাখা উচিত বলে মনে হয় (ইউনিট ও ইন্টিগ্রেশন সংখ্যা অপরিবর্তিত ধরে)?
ইউনিট + ইন্টিগ্রেশনের সময় ইতিমধ্যে ১২০ms + ৬২৫ms = ৭৪৫ms। ৫,০০০ms বাজেটের মধ্যে অবশিষ্ট থাকে প্রায় ৪,২৫৫ms, যা ৩০০ms দিয়ে ভাগ করলে প্রায় ১৪টি E2E টেস্ট পর্যন্ত অনুমতি দেয় — বর্তমান ৫টির চেয়ে বেশি রাখা যায়, কিন্তু তার বেশি বাড়ালে বাজেট ছাড়িয়ে যাবে। এই ধরনের হিসাব বাস্তবে CI বাজেট ঠিক করতে ব্যবহৃত হয়।
-
পরীক্ষা করুন: উপরের কোড সেলে
COST_MS["e2e"]-কে300থেকে800-এ পরিবর্তন করে Run চেপে দেখুন speedup সংখ্যাটি কীভাবে বদলায়।E2E খরচ ৮০০ms হলে পিরামিড স্যুটের মোট সময় হবে ১২০ + ৬২৫ + (৫×৮০০=৪০০০) = ৪,৭৪৫ms, আর উল্টানো স্যুটের মোট সময় হবে ৫ + ৬২৫ + (১২০×৮০০=৯৬,০০০) = ৯৬,৬৩০ms — speedup বেড়ে প্রায় ২০.৪× হবে। E2E যত ধীর হয়, ভুল অনুপাতের শাস্তি তত বড় হয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, ইন্টিগ্রেশন টেস্টিং, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, অ্যাডভান্সড টেকনিক ও CI/CD ইন্টিগ্রেশন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- ফুল-স্ট্যাক অ্যাপের জন্য টেস্টিং পিরামিড সহোদর কোর্স এই পাঠের সাধারণ পিরামিড ধারণাকে একটি ওয়েব অ্যাপের নির্দিষ্ট স্তরে প্রয়োগ করে দেখায়।
- মোবাইল টেস্টিং পিরামিড সহোদর কোর্স একই পিরামিড ধারণা মোবাইল অ্যাপের ভিউমডেল/সার্ভিস/UI স্তরে প্রয়োগ করে দেখায়।