একটি উপাদান বা সিস্টেমের জন্য পরীক্ষার কৌশল ডিজাইন করার সময়, তিনটি সম্পর্কিত পরীক্ষার দিক রয়েছে:
- ব্যাপ্তি : পরীক্ষার কতটা কোড স্পর্শ করে? পরীক্ষাগুলি একটি একক পদ্ধতি, সম্পূর্ণ অ্যাপ্লিকেশন বা এর মধ্যে কোথাও যাচাই করতে পারে। পরীক্ষিত স্কোপটি পরীক্ষার অধীনে এবং সাধারণত এটিকে সাবজেক্ট আন্ডার টেস্ট হিসাবে উল্লেখ করা হয়, যদিও সিস্টেম আন্ডার টেস্ট বা ইউনিট আন্ডার টেস্ট ।
- গতি : পরীক্ষা কত দ্রুত চলে? পরীক্ষার গতি মিলি-সেকেন্ড থেকে কয়েক মিনিট পর্যন্ত পরিবর্তিত হতে পারে।
- বিশ্বস্ততা : কিভাবে "বাস্তব বিশ্ব" পরীক্ষা হয়? উদাহরণ স্বরূপ, আপনি যে কোডটি পরীক্ষা করছেন তার অংশ যদি একটি নেটওয়ার্ক অনুরোধ করার প্রয়োজন হয়, তাহলে পরীক্ষার কোডটি কি আসলেই এই নেটওয়ার্ক অনুরোধ করে, নাকি এটি ফলাফল জাল করে? যদি পরীক্ষাটি আসলে নেটওয়ার্কের সাথে কথা বলে, এর মানে হল এটির বিশ্বস্ততা বেশি। ট্রেড-অফ হল পরীক্ষাটি চালানোর জন্য বেশি সময় লাগতে পারে, নেটওয়ার্ক ডাউন থাকলে ত্রুটি হতে পারে বা ব্যবহার করা ব্যয়বহুল হতে পারে।
কীভাবে আপনার পরীক্ষার কৌশল নির্ধারণ করা শুরু করবেন তা শিখতে কী পরীক্ষা করবেন তা দেখুন।
বিচ্ছিন্নতা এবং নির্ভরতা
আপনি যখন একটি উপাদান বা উপাদানগুলির সিস্টেম পরীক্ষা করেন তখন আপনি এটি বিচ্ছিন্নভাবে করেন। উদাহরণস্বরূপ, একটি ভিউমডেল পরীক্ষা করার জন্য আপনাকে একটি এমুলেটর শুরু করতে এবং একটি UI চালু করতে হবে না কারণ এটি Android ফ্রেমওয়ার্কের উপর নির্ভর করে না (বা উচিত নয়)৷
যাইহোক, পরীক্ষার অধীনে বিষয় কাজ করার জন্য অন্যদের উপর নির্ভর করতে পারে। উদাহরণস্বরূপ, একটি ViewModel কাজ করার জন্য একটি ডেটা সংগ্রহস্থলের উপর নির্ভর করতে পারে।
যখন আপনাকে পরীক্ষার অধীনে একটি বিষয়ের উপর নির্ভরতা প্রদান করতে হবে, তখন একটি সাধারণ অভ্যাস হল একটি টেস্ট ডবল (বা টেস্ট অবজেক্ট ) তৈরি করা। টেস্ট ডাবল হল এমন বস্তু যা আপনার অ্যাপের উপাদান হিসেবে দেখায় এবং কাজ করে কিন্তু সেগুলি একটি নির্দিষ্ট আচরণ বা ডেটা প্রদান করার জন্য আপনার পরীক্ষায় তৈরি করা হয়। প্রধান সুবিধা হল যে তারা আপনার পরীক্ষা দ্রুত এবং সহজ করে তোলে।
পরীক্ষা দ্বিগুণ প্রকার
বিভিন্ন ধরনের টেস্ট ডাবল আছে:
| জাল | একটি টেস্ট ডবল যার ক্লাসের "কাজ" বাস্তবায়ন রয়েছে, কিন্তু এটি এমনভাবে প্রয়োগ করা হয় যা পরীক্ষার জন্য ভাল কিন্তু উৎপাদনের জন্য অনুপযুক্ত। উদাহরণ: একটি ইন-মেমরি ডাটাবেস। নকলের জন্য উপহাসের কাঠামোর প্রয়োজন হয় না এবং এটি হালকা। তারা পছন্দের হয়। |
|---|---|
| উপহাস | একটি পরীক্ষা দ্বিগুণ যা আচরণ করে যে আপনি কীভাবে এটি আচরণ করার জন্য প্রোগ্রাম করেন এবং এটির মিথস্ক্রিয়া সম্পর্কে প্রত্যাশা থাকে। Mocks পরীক্ষায় ব্যর্থ হবে যদি তাদের মিথস্ক্রিয়া আপনার সংজ্ঞায়িত প্রয়োজনীয়তার সাথে মেলে না। এই সব অর্জন করার জন্য সাধারণত একটি উপহাস কাঠামোর সাথে উপহাস তৈরি করা হয়। উদাহরণ: যাচাই করুন যে ডাটাবেসের একটি পদ্ধতি ঠিক একবার কল করা হয়েছিল। |
| স্টাব | একটি পরীক্ষা দ্বিগুণ যা আচরণ করে যে আপনি কীভাবে এটি আচরণ করার জন্য প্রোগ্রাম করেন তবে এর মিথস্ক্রিয়া সম্পর্কে প্রত্যাশা নেই। সাধারণত একটি উপহাস কাঠামো দিয়ে তৈরি করা হয়। সরলতার জন্য স্টাবগুলির চেয়ে নকলগুলি পছন্দ করা হয়। |
| ডামি | একটি পরীক্ষা দ্বিগুণ যা চারপাশে পাস করা হয় কিন্তু ব্যবহার করা হয় না, যেমন আপনাকে শুধুমাত্র একটি প্যারামিটার হিসাবে এটি প্রদান করতে হবে। উদাহরণ: একটি খালি ফাংশন একটি ক্লিক কলব্যাক হিসাবে পাস। |
| গুপ্তচর | একটি বাস্তব বস্তুর উপর একটি মোড়ক যা কিছু অতিরিক্ত তথ্য ট্র্যাক রাখে, উপহাসের মতো। তারা সাধারণত জটিলতা যোগ করার জন্য এড়ানো হয়. নকল বা উপহাস তাই গুপ্তচরদের চেয়ে পছন্দ করা হয়। |
| ছায়া | রোবোলেক্ট্রিকে ব্যবহৃত নকল। |
একটি জাল ব্যবহার উদাহরণ
ধরুন আপনি একটি ViewModel কে ইউনিট পরীক্ষা করতে চান যা UserRepository নামক একটি ইন্টারফেসের উপর নির্ভর করে এবং একটি UI-তে প্রথম ব্যবহারকারীর নাম প্রকাশ করে। আপনি ইন্টারফেস প্রয়োগ করে এবং পরিচিত ডেটা ফেরত দিয়ে একটি জাল পরীক্ষার ডবল তৈরি করতে পারেন।
object FakeUserRepository : UserRepository {
fun getUsers() = listOf(UserAlice, UserBob)
}
val const UserAlice = User("Alice")
val const UserBob = User("Bob")
এই নকল UserRepository স্থানীয় এবং দূরবর্তী ডেটা উত্সগুলির উপর নির্ভর করার প্রয়োজন নেই যা উত্পাদন সংস্করণ ব্যবহার করবে৷ ফাইলটি পরীক্ষার উত্স সেটে থাকে এবং উত্পাদন অ্যাপের সাথে পাঠানো হবে না।
নিম্নলিখিত পরীক্ষাটি যাচাই করে যে ViewModel সঠিকভাবে প্রথম ব্যবহারকারীর নামটি ভিউতে প্রকাশ করে।
@Test
fun viewModelA_loadsUsers_showsFirstUser() {
// Given a VM using fake data
val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init
// Verify that the exposed data is correct
assertEquals(viewModel.firstUserName, UserAlice.name)
}
একটি জাল দিয়ে UserRepository প্রতিস্থাপন করা একটি ইউনিট পরীক্ষায় সহজ, কারণ ভিউমডেলটি পরীক্ষক দ্বারা তৈরি করা হয়েছে। যাইহোক, বড় পরীক্ষায় নির্বিচারে উপাদান প্রতিস্থাপন করা চ্যালেঞ্জিং হতে পারে।
উপাদান এবং নির্ভরতা ইনজেকশন প্রতিস্থাপন
যখন পরীক্ষার অধীনে সিস্টেম তৈরির উপর পরীক্ষাগুলির কোনও নিয়ন্ত্রণ থাকে না, তখন পরীক্ষার দ্বিগুণগুলির জন্য উপাদানগুলি প্রতিস্থাপন করা আরও জড়িত হয়ে যায় এবং একটি পরীক্ষাযোগ্য নকশা অনুসরণ করার জন্য আপনার অ্যাপের আর্কিটেকচারের প্রয়োজন হয়৷
এমনকি বড় এন্ড-টু-এন্ড টেস্টগুলিও টেস্ট ডাবল ব্যবহার করে উপকৃত হতে পারে, যেমন একটি যন্ত্রযুক্ত UI পরীক্ষা যা আপনার অ্যাপে সম্পূর্ণ ব্যবহারকারী প্রবাহের মাধ্যমে নেভিগেট করে। সেক্ষেত্রে আপনি আপনার পরীক্ষাকে হারমেটিক করতে চাইতে পারেন। একটি হারমেটিক পরীক্ষা সমস্ত বাহ্যিক নির্ভরতা এড়ায়, যেমন ইন্টারনেট থেকে ডেটা আনা। এটি নির্ভরযোগ্যতা এবং কর্মক্ষমতা উন্নত করে।
আপনি ম্যানুয়ালি এই নমনীয়তা অর্জনের জন্য আপনার অ্যাপটি ডিজাইন করতে পারেন, তবে আমরা পরীক্ষার সময়ে আপনার অ্যাপের উপাদানগুলি প্রতিস্থাপন করতে হিল্টের মতো নির্ভরতা ইনজেকশন ফ্রেমওয়ার্ক ব্যবহার করার পরামর্শ দিই। হিল্ট টেস্টিং গাইড দেখুন।
রোবোলেক্ট্রিক
অ্যান্ড্রয়েডে, আপনি রোবোলেক্ট্রিক ফ্রেমওয়ার্ক ব্যবহার করতে পারেন, যা একটি বিশেষ ধরনের টেস্ট ডবল প্রদান করে। রোবোলেক্ট্রিক আপনাকে আপনার ওয়ার্কস্টেশনে বা আপনার ক্রমাগত ইন্টিগ্রেশন পরিবেশে আপনার পরীক্ষা চালাতে দেয়। এটি একটি এমুলেটর বা ডিভাইস ছাড়াই একটি নিয়মিত JVM ব্যবহার করে। এটি দৃশ্যের স্ফীতি, রিসোর্স লোডিং এবং অ্যান্ড্রয়েড ফ্রেমওয়ার্কের অন্যান্য অংশগুলিকে শ্যাডো বলে টেস্ট ডবল সহ অনুকরণ করে।
রোবোলেক্ট্রিক একটি সিমুলেটর তাই এটি সাধারণ ইউনিট পরীক্ষাগুলিকে প্রতিস্থাপন করা উচিত নয় বা সামঞ্জস্য পরীক্ষা করার জন্য ব্যবহার করা উচিত নয়। এটি গতি প্রদান করে এবং কিছু ক্ষেত্রে কম বিশ্বস্ততার খরচে খরচ কমায়। UI পরীক্ষার জন্য একটি ভাল পদ্ধতি হল রোবোলেক্ট্রিক এবং ইন্সট্রুমেন্টেড পরীক্ষার সাথে তাদের সামঞ্জস্যপূর্ণ করা এবং কার্যকারিতা বা সামঞ্জস্যতা পরীক্ষা করার প্রয়োজনের উপর নির্ভর করে কখন সেগুলি চালানো হবে তা নির্ধারণ করা। এসপ্রেসো এবং কম্পোজ উভয় পরীক্ষাই রোবোলেকট্রিকে চলতে পারে।