মোবাইল টেস্টিং পিরামিড
এই পাঠে যা শিখবেন
- টেস্টিং পিরামিডের তিনটি স্তর — unit, integration, UI/end-to-end — এবং মোবাইল-প্রেক্ষাপটে প্রতিটির অর্থ
- কেন মোবাইল UI টেস্ট ওয়েবের e2e টেস্টের চেয়েও বেশি ব্যয়বহুল — এমুলেটর/রিয়েল ডিভাইসের প্রকৃত ওভারহেড
- Full-Stack Web Frameworks কোর্সের সাথে এই পাঠের সম্পর্ক — কোনটা পুনরাবৃত্তি হবে না
- বাস্তব সংখ্যা দিয়ে হিসাব করে দেখা কেন একটি "উল্টানো পিরামিড" স্যুট মারাত্মকভাবে ধীর হয়ে যায়
১ · তিনটি স্তর — মোবাইল প্রেক্ষাপটে
FSWF কোর্সের L47-এ শেখানো হয়েছে কেন unit টেস্ট সবচেয়ে বেশি সংখ্যায় থাকা উচিত (দ্রুত, সস্তা, বিচ্ছিন্ন লজিক), integration টেস্ট মাঝারি সংখ্যায় (কয়েকটি কম্পোনেন্ট একসাথে), আর end-to-end টেস্ট সবচেয়ে কম সংখ্যায় (ধীর, ব্যয়বহুল, পুরো সিস্টেম)। মোবাইলে এই একই আকৃতি প্রযোজ্য — কিন্তু শীর্ষ স্তরের নাম হয় UI/automation টেস্ট, আর এটি ওয়েবের ব্রাউজার-ভিত্তিক e2e টেস্টের চেয়েও ধীর হতে পারে, কারণ এটি একটি এমুলেটর বুট করা, আসল অ্যাপ ইনস্টল/লঞ্চ করা, স্ক্রিনে জেসচার সিমুলেট করা, এবং রেন্ডারিং সম্পন্ন হওয়ার জন্য অপেক্ষা করার মতো ভারী কাজ করে — একটি হেডলেস ব্রাউজারের চেয়ে অনেক বেশি ওভারহেড।
একটি বিচ্ছিন্ন ফাংশন/ক্লাস (যেমন নেভিগেশন স্ট্যাক বা লাইফসাইকেল মেশিন) — কোনো UI বা ডিভাইস ছাড়াই সরাসরি কল করে পরীক্ষা।
কয়েকটি কম্পোনেন্ট একসাথে (যেমন স্টোর + একাধিক স্ক্রিন) সঠিকভাবে যোগাযোগ করছে কি না তা যাচাই।
এমুলেটর বা রিয়েল ডিভাইসে সম্পূর্ণ অ্যাপ চালিয়ে আসল ট্যাপ/সোয়াইপ সিমুলেট করে পুরো ফ্লো যাচাই — সবচেয়ে ধীর, তাই সবচেয়ে কম সংখ্যায়।
২ · সংখ্যায় প্রমাণ — পিরামিড বনাম উল্টানো পিরামিড
নিচের কোড সেলে দুটো টেস্ট স্যুট তুলনা করা হচ্ছে — দুটোতেই মোট ২৫০টি টেস্ট, এবং প্রতিটি
টেস্ট-টাইপের খরচ (COST_PER_TEST) দুটোতেই হুবহু একই। একমাত্র পার্থক্য —
কোন স্তরে কতগুলো টেস্ট রাখা হয়েছে। এই একটিমাত্র পার্থক্যই মোট সময়ে কতটা প্রভাব ফেলে তা সরাসরি হিসাব করে
দেখা যাক।
# প্রতিটি টেস্ট-টাইপের গড় খরচ (সেকেন্ড) -- ইউনিট সবচেয়ে সস্তা, UI সবচেয়ে ব্যয়বহুল
# (মোবাইলে UI টেস্ট ওয়েবের e2e-এর চেয়েও ধীর -- এমুলেটর/ডিভাইস বুট + জেসচার সিমুলেশন + রেন্ডার অপেক্ষা)
COST_PER_TEST = {
"unit": 0.05, # ৫০ মিলিসেকেন্ড -- সরাসরি ফাংশন কল
"integration": 0.6, # কয়েকটি কম্পোনেন্ট একসাথে চালাতে হয়
"ui": 9.0, # সম্পূর্ণ অ্যাপ বুট + জেসচার সিমুলেশন + রেন্ডার অপেক্ষা
}
def suite_time(counts, cost_per_test):
"""counts = {'unit': n, 'integration': n, 'ui': n} -- মোট সময় (সেকেন্ড) হিসাব করে"""
return sum(counts[kind] * cost_per_test[kind] for kind in cost_per_test)
# বাস্তবসম্মত পিরামিড-আকৃতির স্যুট -- ৭০% unit, ২০% integration, ১০% UI (মোট ২৫০টি টেস্ট)
PYRAMID_SUITE = {"unit": 175, "integration": 50, "ui": 25}
# উল্টানো পিরামিড -- একই মোট ২৫০টি টেস্ট, শুধু অনুপাত উল্টো (বেশিরভাগ ধীরগতির UI টেস্ট)
INVERTED_SUITE = {"unit": 25, "integration": 50, "ui": 175}
pyramid_seconds = suite_time(PYRAMID_SUITE, COST_PER_TEST)
inverted_seconds = suite_time(INVERTED_SUITE, COST_PER_TEST)
print(f"পিরামিড-আকৃতির স্যুট ({sum(PYRAMID_SUITE.values())}টি টেস্ট) : {pyramid_seconds:8.2f} সেকেন্ড ({pyramid_seconds/60:.2f} মিনিট)")
print(f"উল্টানো পিরামিড স্যুট ({sum(INVERTED_SUITE.values())}টি টেস্ট) : {inverted_seconds:8.2f} সেকেন্ড ({inverted_seconds/60:.2f} মিনিট)")
ratio = inverted_seconds / pyramid_seconds
diff = inverted_seconds - pyramid_seconds
print(f"\nউল্টানো পিরামিড, পিরামিড-আকৃতির স্যুটের চেয়ে প্রায় {ratio:.2f} গুণ ধীর -- যদিও দুটোতেই টেস্ট সংখ্যা সমান।")
assert sum(PYRAMID_SUITE.values()) == sum(INVERTED_SUITE.values()) == 250
assert pyramid_seconds < inverted_seconds
print(f"যাচাই সফল: সমান টেস্ট-সংখ্যা ও সমান প্রতি-টেস্ট খরচ সত্ত্বেও, শুধু অনুপাত বদলানোর কারণে সময়ের পার্থক্য {diff:.2f} সেকেন্ড।")COST_PER_TEST ডিকশনারিটি দুটো স্যুটের জন্যই অভিন্ন — কোনো টেস্ট-টাইপের খরচ বদলানো
হয়নি। শুধু PYRAMID_SUITE-এ ৭৫% টেস্ট সস্তা unit স্তরে আর INVERTED_SUITE-এ
৭০% টেস্ট ব্যয়বহুল ui স্তরে — এই একটিমাত্র পুনর্বণ্টনই মোট সময়কে প্রায় ৬ গুণ বাড়িয়ে দেয়। বাস্তব
CI পাইপলাইনে এই পার্থক্যটাই একটি ৪ মিনিটের বনাম ২৭ মিনিটের বিল্ড-ওয়েট হিসেবে ধরা পড়ে।
টেস্টিং পিরামিডের আকৃতি নিছক তাত্ত্বিক নীতি নয় — এটি সরাসরি পরিমাপযোগ্য একটি খরচ-অপ্টিমাইজেশন সিদ্ধান্ত। মোবাইলে UI/automation টেস্টের প্রতি-টেস্ট খরচ ওয়েবের e2e-এর চেয়েও বেশি হওয়ায় (এমুলেটর/রিয়েল-ডিভাইস ওভারহেডের কারণে), পিরামিডের আকৃতি মেনে চলা মোবাইলে আরও বেশি গুরুত্বপূর্ণ — একটি উল্টানো পিরামিড মোবাইল CI-কে অত্যন্ত ধীর করে দিতে পারে। পরের পাঠে (L51) দেখা যাবে কীভাবে একটি সত্যিকারের টেস্ট-রানার দিয়ে এই স্তরগুলোর টেস্ট লেখা ও যাচাই করা হয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ কেন ইউনিট টেস্টের খরচ মোবাইল ও ওয়েবে প্রায় সমান, কিন্তু UI টেস্টের খরচ মোবাইলে ওয়েবের e2e-এর চেয়ে বেশি?
একটি ইউনিট টেস্ট শুধু একটি ফাংশন/ক্লাসকে সরাসরি ইন-প্রসেস কল করে — এখানে প্ল্যাটফর্মের কোনো ভূমিকা নেই, তাই খরচ প্রায় একই থাকে। কিন্তু একটি UI টেস্ট মোবাইলে একটি এমুলেটর বুট করা বা রিয়েল ডিভাইসের সাথে সংযোগ স্থাপন করা, পুরো অ্যাপটি ইনস্টল ও লঞ্চ করা, এবং প্রতিটি জেসচারের পর UI রেন্ডার সম্পন্ন হওয়ার জন্য অপেক্ষা করার মতো ভারী কাজ করে — একটি হেডলেস ব্রাউজারে চলা ওয়েব e2e টেস্টের চেয়ে এই ওভারহেড উল্লেখযোগ্যভাবে বেশি।
প্র ০২
যদি PYRAMID_SUITE-এ unit কমিয়ে integration বাড়ানো হয় (মোট ২৫০ ঠিক রেখে), মোট সময়ের কী হবে?
সময় বাড়বে — কারণ integration প্রতি-টেস্ট (০.৬s) unit প্রতি-টেস্ট (০.০৫s)-এর
চেয়ে ১২ গুণ ব্যয়বহুল। যেকোনো টেস্ট সস্তা স্তর থেকে ব্যয়বহুল স্তরে সরানো হলে, মোট টেস্ট সংখ্যা অপরিবর্তিত
থাকলেও মোট সময় বাড়বেই — suite_time() ফাংশনটি এই সম্পর্কটি সরাসরি অ্যারিথমেটিকভাবে ধরে।
প্র ০৩ একটি টিম কেন ধীরে ধীরে পিরামিড ভেঙে "উল্টানো পিরামিড"-এর দিকে চলে যেতে পারে, যদিও তারা শুরুতে নীতিটা জানত?
UI টেস্ট প্রায়ই "বাস্তব ব্যবহারকারীর অভিজ্ঞতার" সবচেয়ে কাছাকাছি মনে হয়, তাই টিম মনস্তাত্ত্বিকভাবে বেশি আস্থা পায় এবং প্রতিটি নতুন ফিচারের জন্য একটি UI টেস্ট লিখে ফেলে — অথচ একই যুক্তি প্রায়ই একটি সস্তা unit টেস্ট দিয়েই যাচাই করা সম্ভব হতো। সময়ের সাথে এই ছোট ছোট সিদ্ধান্তগুলো জমতে জমতে UI স্তরটাকেই সবচেয়ে বড় করে ফেলে — উপরের কোডে দেখা গেছে এর ফলাফল কতটা ব্যয়বহুল হতে পারে।
অনুশীলন
-
চিন্তা করুন: ধরুন আপনি একটি বাগ ঠিক করেছেন যেখানে নেভিগেশন স্ট্যাকের
pop()মেথড ভুলভাবে root screen-ও সরিয়ে দিচ্ছিল। এই বাগ পুনরায় না ঘটার নিশ্চয়তা দিতে আপনি কোন স্তরে (unit, integration, নাকি UI) একটি টেস্ট যোগ করবেন, এবং কেন?এটি
unitস্তরে যাচাই করাই সবচেয়ে যুক্তিসঙ্গত — নেভিগেশন স্ট্যাক ক্লাসটি একটি বিচ্ছিন্ন লজিক ইউনিট, কোনো UI বা ডিভাইস ছাড়াই সরাসরিpop()কল করে ফলাফল যাচাই করা যায়। একটি পুরো UI টেস্ট লেখাও সম্ভব (বাস্তবে স্ক্রিন থেকে ব্যাক করে দেখা), কিন্তু সেটি ৯ সেকেন্ড খরচ করবে যেখানে একটি unit টেস্ট ৫০ মিলিসেকেন্ডেই একই যুক্তি ১০০% নিশ্চিতভাবে যাচাই করে দিতে পারে — ঠিক পিরামিড নীতিরই বাস্তব প্রয়োগ। -
পরীক্ষা করুন: উপরের কোড সেলে
COST_PER_TEST["ui"]-এর মান9.0থেকে15.0-এ পরিবর্তন করুন (ধরে নিন টিমের CI এমুলেটর অবকাঠামো আরও ধীর) এবং কোডটি আবার চালিয়ে দেখুনratio-এর মান কীভাবে বদলায়।uiখরচ বাড়ানোর পরinverted_secondsআরও বেশি বাড়বে (যেহেতুINVERTED_SUITE-এ ১৭৫টি UI টেস্ট আছে, প্রতিটির খরচ বৃদ্ধি ১৭৫ গুণ হয়ে যোগ হয়), অথচpyramid_secondsসামান্যই বাড়বে (মাত্র ২৫টি UI টেস্ট থাকায়)। ফলেratio৬.০৯ থেকে আরও বড় হবে — এটাই দেখায় ধীরগতির অবকাঠামোতে পিরামিডের আকৃতি মেনে চলার গুরুত্ব আরও বেড়ে যায়, কমে না।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- FSWF · The Testing Pyramid for Full-Stack Apps সহোদর পাঠ টেস্টিং পিরামিডের সাধারণ সংজ্ঞা ও ওয়েব-প্রেক্ষাপটের বিস্তারিত এই পাঠেই তৈরি হয়েছে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।