স্ক্রিনশট টেস্টিং হল আপনার অ্যাপের UI যাচাই করার একটি খুব কার্যকর উপায়। কম্পোনেন্ট, ফিচার ও অ্যাপ্লিকেশন টেস্টে স্ক্রিনশট টেস্ট থাকতে পারে।
আপনি ইন্সট্রুমেন্টেড ও লোকাল স্ক্রিনশট টেস্ট, দু'টিই তৈরি করার জন্য থার্ড-পার্টি টুল ব্যবহার করতে পারবেন। আপনি Compose ব্যবহার করলে, অফিসিয়াল Compose প্রিভিউ স্ক্রিনশট টেস্টিং টুল ব্যবহার করতে পারবেন।
সংজ্ঞা
স্ক্রিনশট টেস্ট UI-এর স্ক্রিনশট নেয় এবং এটিকে আগে অনুমোদিত ছবির সাথে তুলনা করে, যাকে "রেফারেন্স" বা "গোল্ডেন" বলা হয়:
ছবিগুলি একই হলে, পরীক্ষাটি পাস করে। দু'টির মধ্যে কোনও পার্থক্য থাকলে, টুল একটি রিপোর্ট তৈরি করে:
অভিযোগের ভিত্তিতে, আপনার কাছে দুটি সম্ভাব্য উত্তর আছে:
- বুঝতে পারেন যে নতুন কোডে কোনও সমস্যা আছে এবং সেটি সমাধান করেন।
- নতুন স্ক্রিনশট অনুমোদন করুন এবং রেফারেন্স ছবিটির জায়গায় নতুন ছবিটি যোগ করুন।
স্ক্রিনশট টেস্টের ওয়ার্কফ্লো সাধারণ টেস্টের থেকে আলাদা, কারণ কোনও টেস্ট ব্যর্থ হলেই যে সেটিতে সমস্যা আছে তা নয়।
সুবিধা
সুবিধা বা স্ক্রিনশট টেস্ট হল:
- স্ক্রিনশট টেস্ট, প্রতিটি টেস্টে একাধিক অ্যাসার্শন করে। যেমন, একটি পরীক্ষা রঙ, মার্জিন, সাইজ ও ফন্ট চেক করতে পারে।
- স্ক্রিনশট টেস্ট লেখা, বোঝা ও ম্যানেজ করা, সমতুল্য আচরণ টেস্টের চেয়ে অনেক সহজ।
- বিভিন্ন স্ক্রিন সাইজে যাচাইকরণ ও রিগ্রেশন ধরার ক্ষেত্রে এগুলি বিশেষভাবে উপযোগী।
অসুবিধা
তবে, স্ক্রিনশট টেস্টের কিছু অসুবিধাও থাকতে পারে:
- রেফারেন্স ছবি নিয়ে কাজ করা বেশ কঠিন হতে পারে, কারণ বড় প্রোজেক্টে হাজার হাজার PNG ফাইল থাকতে পারে।
- আলাদা আলাদা প্ল্যাটফর্ম (Linux, Max ও Windows) থেকে সামান্য আলাদা স্ক্রিনশট পাওয়া যায়।
- এগুলি সমতুল্য আচরণ পরীক্ষার থেকে ধীর গতির হয়।
- স্ক্রিনশট টেস্টের সংখ্যা বেশি হলে সমস্যা হতে পারে, যেমন একটি পরিবর্তন হাজার হাজার স্ক্রিনশটকে প্রভাবিত করলে।
নিম্নলিখিত বিভাগে এইসব সমস্যার সমাধান করার ব্যাপারে সাজেশন দেওয়া হয়েছে।
স্ক্রিনশট টেস্টের সংখ্যা ন্যূনতম রাখুন
রিগ্রেশন সংক্রান্ত ফিডব্যাক ও কভারেজ সর্বাধিক করার সময় আপনাকে স্ক্রিনশট টেস্টের সংখ্যা কমিয়ে আনতে হবে।
বিভিন্ন UI স্টেটের কম্বিনেশন খুব দ্রুত পরীক্ষার সংখ্যা বাড়িয়ে দিতে পারে। আপনার অ্যাপের UI-এর একটি অংশ যাচাই করার কিছু উপায় নিচে উল্লেখ করা হল:
- বিভিন্ন থিমের উপর
- বিভিন্ন ফন্ট সাইজ ব্যবহার করা
- আলাদা আলাদা স্ক্রিন সাইজ বা বাউন্ডের মধ্যে
আপনি যদি আপনার অ্যাপের প্রতিটি কম্পোনেন্ট, লেআউট এবং স্ক্রিনের জন্য এটি করেন, তাহলে আপনার কাছে হাজার হাজার স্ক্রিনশট ফাইল থাকবে, যার বেশিরভাগই আপনাকে কোনও অতিরিক্ত ফিডব্যাক দেবে না।
যেমন, আপনি যদি হালকা ও গাঢ় থিমের সাথে কাস্টম বোতাম এবং ৩টি ফন্ট সাইজ পরীক্ষা করতে চান, তাহলে আপনাকে সেগুলির সবকটি কম্বিনেশন তৈরি করতে হবে না। পরিবর্তে, আপনি যেকোনও একটি থিম বেছে নিতে পারেন। এর কারণ হল, বোতামটি বড় শব্দের সাথে যেভাবে প্রতিক্রিয়া দেখায়, তার কোনও প্রভাব থিমের উপর পড়ে না।
রেফারেন্স ইমেজ স্টোর করা
রেফারেন্স (বা গোল্ডেন) ইমেজ সাধারণত PNG ফাইল হয় যা আপনার সোর্স কন্ট্রোলে চেক-ইন করা যেতে পারে। তবে, Git এবং বেশিরভাগ সোর্স কন্ট্রোল ম্যানেজার টেক্সট ফাইলের জন্য অপ্টিমাইজ করা হয়, বড় বাইনারি ফাইলের জন্য নয়।
এইসব ফাইল ম্যানেজ করার জন্য আপনার কাছে ৩টি বিকল্প আছে:
- git ব্যবহার করা চালিয়ে যান, তবে স্টোরেজ ব্যবহার কমানোর চেষ্টা করুন।
- Git LFS ব্যবহার করুন।
- স্ক্রিনশট ম্যানেজ করতে ক্লাউড পরিষেবা ব্যবহার করুন।
প্ল্যাটফর্মের পার্থক্য
স্ক্রিনশট টেস্ট, টেক্সট বা শ্যাডোর মতো নির্দিষ্ট ফিচার ড্র করার জন্য লো-লেভেল প্ল্যাটফর্ম API-এর উপর নির্ভর করে এবং প্ল্যাটফর্ম সেগুলি বিভিন্ন উপায়ে প্রয়োগ করতে পারে। আপনি Mac-এ ডেভেলপ করলে এবং লোকাল স্টোরেজে নতুন স্ক্রিনশট সেভ করলে, Linux CI মেশিনে টেস্ট ভেঙে গেছে বলে দেখতে পেতে পারেন।
সমস্যাটি সমাধান করার ২টি উপায় আছে:
- সামান্য পরিবর্তন মেনে নেওয়া
- কোনও সার্ভারে স্ক্রিনশট নেওয়া
সামান্য পরিবর্তন মেনে নেওয়া
দুটি স্ক্রিনশট তুলনা করার সময় সামান্য পার্থক্যকে উপেক্ষা করার জন্য আপনি বেশিরভাগ স্ক্রিনশট টেস্টিং লাইব্রেরি কনফিগার করতে পারবেন।
এর জন্য দুটি পদ্ধতি আছে:
- পরিবর্তিত পিক্সেলের শতাংশ বা পিক্সেল ভ্যালুতে মোট পার্থক্যের শতাংশের উপর ভিত্তি করে টলারেন্স কনফিগার করুন।
- পিক্সেলের পরিবর্তে গঠনগত ও শব্দার্থগত মিল আছে কিনা তা যাচাই করতে, স্ক্রিনশট তুলনা করে এমন একটি স্মার্ট ডিফার অ্যালগরিদম ব্যবহার করুন।
এই পদ্ধতির অসুবিধা হল, এটি ফলস পজিটিভ তৈরি করতে পারে এবং থ্রেশহোল্ডের নিচে থাকা বা ভুলবশত যথেষ্ট একই রকম বলে বিবেচিত হওয়া ভুলগুলি ধরতে পারে না।
কোনও সার্ভারে স্ক্রিনশট নেওয়া
পিক্সেল-পারফেক্ট স্ক্রিনশট কম্পারেটর ব্যবহার করতে হলে, আপনার টেস্ট একই পরিস্থিতিতে স্ক্রিনশট নেয় কিনা তা নিশ্চিত করতে হবে। এটি করতে, আপনি নিজের কন্টিনিউয়াস ইন্টিগ্রেশন (CI) সিস্টেম ব্যবহার করতে পারেন অথবা ক্লাউড পরিষেবা ব্যবহার করতে পারেন।
যেমন, আপনার CI ওয়ার্কফ্লোতে এমন একটি ধাপ তৈরি করতে পারেন যা নিম্নলিখিত কাজগুলি করে:
- স্ক্রিনশট টেস্ট রান করে (শুধু তখনই প্রয়োজন হয় যখন পিক্সেল-পারফেক্ট ম্যাচিং ব্যবহার করা হয় না)।
- আগের ধাপটি সম্পূর্ণ না হলে নতুন স্ক্রিনশট রেকর্ড করে।
- ব্রাঞ্চে নতুন ফাইল কমিট করে।
এই পদ্ধতি ব্যবহার করলে, CI-তে স্ক্রিনশট টেস্ট কখনওই ব্যর্থ হয় না, তবে এটি আপনার জন্য পরিবর্তন করে। এইভাবে, আপনি এবং পরিবর্তন পর্যালোচকরা পরিবর্তন মার্জ করে নতুন স্ক্রিনশট গ্রহণ করতে পারবেন।
স্ক্রিনশট টেস্টিং টুল
স্ক্রিনশট টেস্টিংয়ের জন্য উপলভ্য টুল ও লাইব্রেরির মধ্যে নিম্নলিখিত মূল পার্থক্যগুলি বিবেচনা করুন:
- এনভায়রনমেন্ট: হোস্টের উপর রান করা লোকাল টেস্ট অথবা এমুলেটর বা ডিভাইসে রান করা ইনস্ট্রুমেন্টেড টেস্ট।
- রেন্ডারিং ইঞ্জিন: হোস্ট-সাইড স্ক্রিনশট সলিউশন, Layoutlib—প্রিভিউয়ের জন্য Android
Studio-এর রেন্ডারিং ইঞ্জিন—অথবা Robolectric Native Graphics (RNG) ব্যবহার করতে পারে।
- Layoutlib-ভিত্তিক ফ্রেমওয়ার্ক স্ট্যাটিক কম্পোনেন্ট রেন্ডার করার উপর ফোকাস করে, আলাদা আলাদা আচরণ দেখানোর জন্য বিভিন্ন স্টেট ব্যবহার করে। এগুলি সাধারণত ব্যবহার করা সহজ।
- RNG-এর সাথে ইন্টিগ্রেট করা ফ্রেমওয়ার্কগুলি Robolectric-এর সব ফিচার ব্যবহার করতে পারে, এর ফলে আরও বড় স্কোপ নিয়ে পরীক্ষা করা যায়।