বড় পরীক্ষা স্থায়িত্ব

মোবাইল অ্যাপ্লিকেশন এবং ফ্রেমওয়ার্কের অ্যাসিঙ্ক্রোনাস প্রকৃতি প্রায়শই এটিকে নির্ভরযোগ্য এবং পুনরাবৃত্তিযোগ্য পরীক্ষা লিখতে চ্যালেঞ্জ করে তোলে। যখন একটি ব্যবহারকারী ইভেন্ট ইনজেকশন করা হয়, পরীক্ষার কাঠামোটি অ্যাপটির প্রতিক্রিয়া শেষ করার জন্য অপেক্ষা করতে হবে, যা স্ক্রিনে কিছু পাঠ্য পরিবর্তন থেকে শুরু করে একটি কার্যকলাপের সম্পূর্ণ বিনোদন পর্যন্ত হতে পারে। যখন একটি পরীক্ষায় একটি নির্ধারক আচরণ থাকে না, তখন এটি অস্বস্তিকর ।

কম্পোজ বা এসপ্রেসোর মতো আধুনিক ফ্রেমওয়ার্কগুলি পরীক্ষাকে মাথায় রেখে ডিজাইন করা হয়েছে তাই একটি নির্দিষ্ট গ্যারান্টি রয়েছে যে পরবর্তী পরীক্ষার পদক্ষেপ বা দাবির আগে UI নিষ্ক্রিয় থাকবে। এটি সিঙ্ক্রোনাইজেশন ।

টেস্ট সিঙ্ক্রোনাইজেশন

আপনি যখন পরীক্ষায় অজানা অ্যাসিঙ্ক্রোনাস বা ব্যাকগ্রাউন্ড অপারেশন চালান, যেমন ডাটাবেস থেকে ডেটা লোড করা বা অসীম অ্যানিমেশন দেখানোর মতো সমস্যাগুলি এখনও দেখা দিতে পারে।

আপনার টেস্ট স্যুটের নির্ভরযোগ্যতা বাড়াতে, আপনি ব্যাকগ্রাউন্ড অপারেশন ট্র্যাক করার একটি উপায় ইনস্টল করতে পারেন, যেমন Espresso Idling Resources । এছাড়াও, আপনি পরীক্ষামূলক সংস্করণগুলির জন্য মডিউলগুলি প্রতিস্থাপন করতে পারেন যা আপনি অলসতার জন্য অনুসন্ধান করতে পারেন বা যা সিঙ্ক্রোনাইজেশন উন্নত করতে পারে, যেমন coroutines-এর জন্য TestDispatcher বা RxJava-এর জন্য RxIdler ৷

স্থিতিশীলতা উন্নত করার উপায়

বড় পরীক্ষাগুলি একই সময়ে প্রচুর রিগ্রেশন ধরতে পারে কারণ তারা একটি অ্যাপের একাধিক উপাদান পরীক্ষা করে। তারা সাধারণত এমুলেটর বা ডিভাইসে চলে, যার মানে তাদের উচ্চ বিশ্বস্ততা রয়েছে। যদিও বৃহৎ এন্ড-টু-এন্ড পরীক্ষাগুলি ব্যাপক কভারেজ প্রদান করে, তারা মাঝে মাঝে ব্যর্থতার প্রবণতা বেশি।

অস্থিরতা কমাতে আপনি যে প্রাথমিক ব্যবস্থা নিতে পারেন তা হল:

• সঠিকভাবে ডিভাইস কনফিগার করুন
• সিঙ্ক্রোনাইজেশন সমস্যা প্রতিরোধ করুন
• পুনরায় চেষ্টা বাস্তবায়ন করুন

কম্পোজ বা এসপ্রেসো ব্যবহার করে বড় পরীক্ষা তৈরি করতে, আপনি সাধারণত আপনার কার্যকলাপগুলির একটি শুরু করেন এবং একজন ব্যবহারকারীর মত নেভিগেট করেন, যাচাই করে যে UI দাবী বা স্ক্রিনশট পরীক্ষা ব্যবহার করে সঠিকভাবে আচরণ করে।

অন্যান্য ফ্রেমওয়ার্ক, যেমন UI অটোমেটর , একটি বৃহত্তর সুযোগের জন্য অনুমতি দেয়, কারণ আপনি সিস্টেম UI এবং অন্যান্য অ্যাপের সাথে ইন্টারঅ্যাক্ট করতে পারেন। যাইহোক, UI অটোমেটর পরীক্ষাগুলির জন্য আরও ম্যানুয়াল সিঙ্ক্রোনাইজেশনের প্রয়োজন হতে পারে তাই তারা কম নির্ভরযোগ্য হতে থাকে।

ডিভাইস কনফিগার করুন

প্রথমত, আপনার পরীক্ষাগুলির নির্ভরযোগ্যতা উন্নত করতে, আপনাকে নিশ্চিত করতে হবে যে ডিভাইসের অপারেটিং সিস্টেম অপ্রত্যাশিতভাবে পরীক্ষাগুলি সম্পাদনে বাধা সৃষ্টি করে না। উদাহরণস্বরূপ, যখন একটি সিস্টেম আপডেট ডায়ালগ অন্যান্য অ্যাপের উপরে দেখানো হয় বা যখন ডিস্কে স্থান অপর্যাপ্ত হয়।

ডিভাইস ফার্ম প্রদানকারীরা তাদের ডিভাইস এবং এমুলেটর কনফিগার করে যাতে সাধারণত আপনাকে কোনো পদক্ষেপ নিতে হবে না। যাইহোক, বিশেষ ক্ষেত্রে তাদের নিজস্ব কনফিগারেশন নির্দেশিকা থাকতে পারে।

গ্রেডল-পরিচালিত ডিভাইস

যদি আপনি নিজে এমুলেটরগুলি পরিচালনা করেন তবে আপনার পরীক্ষা চালানোর জন্য কোন ডিভাইসগুলি ব্যবহার করতে হবে তা নির্ধারণ করতে আপনি Gradle-পরিচালিত ডিভাইসগুলি ব্যবহার করতে পারেন:

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

এই কনফিগারেশনের সাথে, নিম্নলিখিত কমান্ডটি একটি এমুলেটর চিত্র তৈরি করবে, একটি উদাহরণ শুরু করবে, পরীক্ষা চালাবে এবং এটি বন্ধ করবে।

./gradlew pixel2api30DebugAndroidTest

গ্রেডল-পরিচালিত ডিভাইসগুলিতে ডিভাইস সংযোগ বিচ্ছিন্ন এবং অন্যান্য উন্নতির ক্ষেত্রে পুনরায় চেষ্টা করার প্রক্রিয়া রয়েছে।

সিঙ্ক্রোনাইজেশন সমস্যা প্রতিরোধ করুন

যে উপাদানগুলি ব্যাকগ্রাউন্ড বা অ্যাসিঙ্ক্রোনাস ক্রিয়াকলাপগুলি করে সেগুলি পরীক্ষার ব্যর্থতার কারণ হতে পারে কারণ UI এর জন্য প্রস্তুত হওয়ার আগে একটি পরীক্ষার বিবৃতি কার্যকর করা হয়েছিল। পরীক্ষার পরিধি বাড়ার সাথে সাথে এটি ফ্ল্যাকি হওয়ার সম্ভাবনা বাড়ায়। এই সিঙ্ক্রোনাইজেশন সমস্যাগুলি ফ্ল্যাকিনেসের একটি প্রাথমিক উত্স কারণ পরীক্ষার ফ্রেমওয়ার্কগুলিকে অনুমান করতে হবে যে কোনও অ্যাক্টিভিটি লোড করা হয়েছে কিনা বা এটি আরও অপেক্ষা করা উচিত কিনা।

সমাধান

কোন অ্যাপ কখন ব্যস্ত থাকে তা নির্দেশ করতে আপনি Espresso-এর অলস রিসোর্স ব্যবহার করতে পারেন, কিন্তু প্রতিটি অ্যাসিঙ্ক্রোনাস অপারেশন ট্র্যাক করা কঠিন, বিশেষ করে খুব বড় এন্ড-টু-এন্ড পরীক্ষায়। এছাড়াও, অলস সংস্থানগুলি পরীক্ষার অধীনে কোডকে দূষিত না করে ইনস্টল করা কঠিন হতে পারে।

কোনও কার্যকলাপ ব্যস্ত কিনা তা অনুমান করার পরিবর্তে, নির্দিষ্ট শর্ত পূরণ না হওয়া পর্যন্ত আপনি আপনার পরীক্ষাগুলিকে অপেক্ষা করতে পারেন। উদাহরণস্বরূপ, আপনি UI এ একটি নির্দিষ্ট পাঠ্য বা উপাদান দেখানো পর্যন্ত অপেক্ষা করতে পারেন।

কম্পোজে বিভিন্ন ম্যাচারদের জন্য অপেক্ষা করার জন্য ComposeTestRule এর অংশ হিসাবে টেস্টিং API-এর একটি সংগ্রহ রয়েছে:

fun waitUntilAtLeastOneExists(matcher: SemanticsMatcher, timeout: Long = 1000L)

fun waitUntilDoesNotExist(matcher: SemanticsMatcher, timeout: Long = 1000L)

fun waitUntilExactlyOneExists(matcher: SemanticsMatcher,  timeout: Long = 1000L)

fun waitUntilNodeCount(matcher: SemanticsMatcher, count: Int, timeout: Long = 1000L)

এবং একটি জেনেরিক API যা কোনো ফাংশন নেয় যা একটি বুলিয়ান রিটার্ন করে:

fun waitUntil(timeoutMillis: Long, condition: () -> Boolean): Unit

উদাহরণ ব্যবহার:

composeTestRule.waitUntilExactlyOneExists(hasText("Continue")</code>)</p></td>

প্রক্রিয়া পুনরায় চেষ্টা করুন

আপনার ফ্ল্যাকি পরীক্ষাগুলি ঠিক করা উচিত, তবে কখনও কখনও এমন শর্তগুলি যা তাদের ব্যর্থ করে দেয় তা এতটাই অসম্ভব যে তাদের পুনরুত্পাদন করা কঠিন। যদিও আপনার সর্বদা ট্র্যাক রাখা উচিত এবং ফ্লেকি পরীক্ষাগুলি ঠিক করা উচিত, একটি পুনঃপ্রচেষ্টা পদ্ধতি পরীক্ষাটি পাস না হওয়া পর্যন্ত কয়েকবার চালিয়ে বিকাশকারীর উত্পাদনশীলতা বজায় রাখতে সহায়তা করতে পারে।

সমস্যা প্রতিরোধ করার জন্য একাধিক স্তরে পুনঃপ্রয়াস ঘটতে হবে, যেমন:

• ডিভাইসের সাথে সংযোগের সময় শেষ হয়েছে বা সংযোগ হারিয়েছে৷
• একক পরীক্ষায় ব্যর্থতা

পুনঃপ্রচারগুলি ইনস্টল করা বা কনফিগার করা আপনার পরীক্ষার কাঠামো এবং পরিকাঠামোর উপর নির্ভর করে, তবে সাধারণ প্রক্রিয়াগুলির মধ্যে রয়েছে:

• একটি JUnit নিয়ম যা যেকোন পরীক্ষা বহুবার পুনরায় চেষ্টা করে
• আপনার CI ওয়ার্কফ্লোতে একটি পুনঃপ্রচেষ্টা কর্ম বা পদক্ষেপ
• একটি এমুলেটর পুনরায় চালু করার জন্য একটি সিস্টেম যখন এটি প্রতিক্রিয়াহীন হয়, যেমন গ্রেডল-পরিচালিত ডিভাইস।