টেস্ট ম্যাপিং

এটি পরীক্ষার ম্যাপিংয়ের একটি সংক্ষিপ্ত ভূমিকা এবং অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট (AOSP) এ কীভাবে সহজেই পরীক্ষা কনফিগার করা শুরু করা যায় তার একটি ব্যাখ্যা।

পরীক্ষা ম্যাপিং সম্পর্কে

টেস্ট ম্যাপিং হল একটি গেরিট-ভিত্তিক পদ্ধতি যা ডেভেলপারদের সরাসরি অ্যান্ড্রয়েড সোর্স ট্রিতে প্রি- এবং পোস্ট-সাবমিট পরীক্ষার নিয়ম তৈরি করতে দেয় এবং শাখা এবং ডিভাইসগুলির সিদ্ধান্তগুলি পরীক্ষার পরিকাঠামোতেই পরীক্ষা করার জন্য ছেড়ে দেয়। টেস্ট ম্যাপিং সংজ্ঞা হল TEST_MAPPING নামের JSON ফাইল যা যেকোন উৎস ডিরেক্টরিতে রাখা যেতে পারে।

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

এই উদাহরণগুলি দেখুন:

Service.core-এর জন্য TEST_MAPPING-এ প্রি-সাবমিট পরীক্ষা যোগ করুন

আমদানি ব্যবহার করে সরঞ্জাম/ডেক্সটারের জন্য TEST_MAPPING-এ প্রি-সাবমিট পরীক্ষা যোগ করুন

টেস্ট ম্যাপিং টেস্ট এক্সিকিউশন এবং ফলাফল রিপোর্টিংয়ের জন্য ট্রেড ফেডারেশন (TF) টেস্ট হারনেসের উপর নির্ভর করে।

পরীক্ষার গ্রুপ সংজ্ঞায়িত করুন

টেস্ট ম্যাপিং গ্রুপ পরীক্ষা একটি টেস্ট গ্রুপের মাধ্যমে। একটি পরীক্ষার গ্রুপের নাম যেকোনো স্ট্রিং হতে পারে। উদাহরণস্বরূপ, পরিবর্তনগুলি যাচাই করার সময় পরীক্ষা চালানোর জন্য প্রি-সাবমিট হতে পারে। এবং পোস্ট সাবমিট পরীক্ষাগুলি পরিবর্তনগুলি একত্রিত হওয়ার পরে বিল্ডগুলিকে যাচাই করতে ব্যবহার করা যেতে পারে।

প্যাকেজ বিল্ড স্ক্রিপ্ট নিয়ম

ট্রেড ফেডারেশন টেস্ট হারনেস একটি প্রদত্ত বিল্ডের জন্য টেস্ট ম্যাপিংয়ের পরীক্ষা মডিউলগুলি চালানোর জন্য, এই মডিউলগুলিতে অবশ্যই Soong- এর জন্য test_suite সেট থাকতে হবে বা এই দুটি স্যুটের একটিতে মেক করার জন্য LOCAL_COMPATIBILITY_SUITE সেট থাকতে হবে:

• সাধারণ-পরীক্ষা - যে পরীক্ষাগুলি ডিভাইস-নির্দিষ্ট কার্যকারিতার উপর নির্ভর করে না (যেমন বিক্রেতা-নির্দিষ্ট হার্ডওয়্যার যা বেশিরভাগ ডিভাইসে নেই)। বেশিরভাগ পরীক্ষা সাধারণ-পরীক্ষা স্যুটে হওয়া উচিত, এমনকি যদি সেগুলি একটি ABI বা বিটনেস বা HWASan-এর মতো হার্ডওয়্যার বৈশিষ্ট্যগুলির জন্য নির্দিষ্ট হয় (প্রতিটি ABI-এর জন্য একটি পৃথক test_suites টার্গেট আছে), এবং এমনকি যদি সেগুলিকে একটি ডিভাইসে চালাতে হয়।
• ডিভাইস-পরীক্ষা - পরীক্ষা যা ডিভাইস-নির্দিষ্ট কার্যকারিতার উপর নির্ভর করে। সাধারণত এই পরীক্ষাগুলি vendor/ অধীনে পাওয়া যাবে। কারণ "ডিভাইস-নির্দিষ্ট" ABI বা SoC কার্যকারিতাকে নির্দেশ করে না যা অন্যান্য ডিভাইসে থাকতে পারে বা নাও থাকতে পারে, তবে শুধুমাত্র একটি ডিভাইসের জন্য অনন্য কার্যকারিতার জন্য, এটি GTest নেটিভ টেস্টের মতো প্রতি বিট JUnit পরীক্ষায় প্রযোজ্য (যা সাধারণত করা উচিত) general-tests হতে হবে এমনকি যদি সেগুলি ABI-নির্দিষ্ট হয়)।

উদাহরণ:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

একটি পরীক্ষা স্যুটে চালানোর জন্য পরীক্ষাগুলি কনফিগার করুন

একটি পরীক্ষা স্যুটের ভিতরে চালানোর জন্য, পরীক্ষা:

• কোনো বিল্ড প্রদানকারী থাকতে হবে না।
• এটি শেষ হওয়ার পরে অবশ্যই পরিষ্কার করতে হবে, উদাহরণস্বরূপ, পরীক্ষার সময় উত্পন্ন কোনো অস্থায়ী ফাইল মুছে ফেলার মাধ্যমে।
• সিস্টেম সেটিংস ডিফল্ট বা মূল মান পরিবর্তন করুন।
• একটি নির্দিষ্ট অবস্থায় একটি ডিভাইস অনুমান করা উচিত নয়, যেমন, রুট প্রস্তুত। বেশিরভাগ পরীক্ষা চালানোর জন্য রুট সুবিধার প্রয়োজন হয় না। যদি একটি পরীক্ষার জন্য অবশ্যই রুট প্রয়োজন হয়, তাহলে এটির AndroidTest.xml এ একটি RootTargetPreparer এর সাথে নিম্নলিখিত উদাহরণের মতো উল্লেখ করা উচিত:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

টেস্ট ম্যাপিং ফাইল তৈরি করুন

পরীক্ষার কভারেজ প্রয়োজন এমন ডিরেক্টরির জন্য, নীচের উদাহরণের মতো একটি TEST_MAPPING JSON ফাইল যোগ করুন। এই নিয়মগুলি নিশ্চিত করবে যে পরীক্ষাগুলি প্রি-সাবমিট চেকগুলিতে চালানো হয় যখন কোনও ফাইল সেই ডিরেক্টরি বা এর কোনও সাবডিরেক্টরিতে স্পর্শ করা হয়।

একটি উদাহরণ অনুসরণ করুন

এখানে একটি নমুনা TEST_MAPPING ফাইল রয়েছে (এটি JSON ফর্ম্যাটে কিন্তু মন্তব্য সমর্থিত):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

গুণাবলী সেট করুন

উপরের উদাহরণে, presubmit এবং postsubmit প্রতিটি পরীক্ষার গ্রুপের নাম। পরীক্ষা গোষ্ঠী সম্পর্কে আরও তথ্যের জন্য পরীক্ষা গোষ্ঠীর সংজ্ঞা দেখুন।

পরীক্ষার মডিউলের নাম বা ট্রেড ফেডারেশন ইন্টিগ্রেশন পরীক্ষার নাম (পরীক্ষা XML ফাইলের রিসোর্স পাথ, যেমন, uiautomator/uiautomator-demo ) name বৈশিষ্ট্যের মান সেট করা যেতে পারে। মনে রাখবেন নামের ক্ষেত্রটি ক্লাসের name বা পরীক্ষা পদ্ধতির name ব্যবহার করতে পারে না। চালানোর জন্য পরীক্ষাগুলিকে সংকুচিত করতে, আপনি এখানে include-filter মতো বিকল্পগুলি ব্যবহার করতে পারেন। দেখুন ( অন্তর্ভুক্ত-ফিল্টার নমুনা ব্যবহার )।

একটি পরীক্ষার হোস্ট সেটিং নির্দেশ করে যে পরীক্ষাটি হোস্টে চলমান ডিভাইসবিহীন পরীক্ষা কিনা। ডিফল্ট মান মিথ্যা , যার অর্থ পরীক্ষা চালানোর জন্য একটি ডিভাইস প্রয়োজন৷ সমর্থিত পরীক্ষার ধরনগুলি হল GTest বাইনারিগুলির জন্য HostGTest এবং JUnit পরীক্ষার জন্য HostTest ৷

ফাইল_প্যাটার্নস অ্যাট্রিবিউট আপনাকে যেকোন সোর্স কোড ফাইলের আপেক্ষিক পাথ (টেস্ট_ম্যাপিং ফাইল ধারণকারী ডিরেক্টরির সাথে সম্পর্কিত) মেলানোর জন্য রেজেক্স স্ট্রিংগুলির একটি তালিকা সেট করতে দেয়। উপরের উদাহরণে, টেস্ট CtsWindowManagerDeviceTestCases শুধুমাত্র তখনই প্রিসবমিটে চালানো হবে যখন কোনো জাভা ফাইল উইন্ডো বা অ্যাক্টিভিটি দিয়ে শুরু হয়, যা TEST_MAPPING ফাইলের একই ডিরেক্টরিতে বা এর যেকোনো সাব ডিরেক্টরিতে বিদ্যমান, পরিবর্তন করা হয়। ব্যাকস্ল্যাশগুলিকে পালাতে হবে কারণ সেগুলি একটি JSON ফাইলে রয়েছে৷

আমদানি বৈশিষ্ট্য আপনাকে সামগ্রী অনুলিপি না করে অন্যান্য TEST_MAPPING ফাইলগুলিতে পরীক্ষা অন্তর্ভুক্ত করার অনুমতি দেয়৷ নোট করুন যে আমদানি করা পথের মূল ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিও অন্তর্ভুক্ত করা হবে৷ টেস্ট ম্যাপিং নেস্টেড আমদানির অনুমতি দেয়; এর অর্থ হল দুটি TEST_MAPPING ফাইল একে অপরকে আমদানি করতে পারে এবং টেস্ট ম্যাপিং অন্তর্ভুক্ত পরীক্ষাগুলিকে যথাযথভাবে একত্রিত করতে সক্ষম।

অপশন অ্যাট্রিবিউটে অতিরিক্ত ট্রেডফেড কমান্ড লাইন বিকল্প রয়েছে।

একটি প্রদত্ত পরীক্ষার জন্য উপলব্ধ বিকল্পগুলির একটি সম্পূর্ণ তালিকা পেতে, চালান:

tradefed.sh run commandAndExit [test_module] --help

বিকল্পগুলি কীভাবে কাজ করে সে সম্পর্কে আরও বিশদে জানতে TradeFed অপশন হ্যান্ডলিং দেখুন।

Atest দিয়ে পরীক্ষা চালান

স্থানীয়ভাবে প্রি-সাবমিট পরীক্ষার নিয়মগুলি সম্পাদন করতে:

1. TEST_MAPPING ফাইল ধারণকারী ডিরেক্টরিতে যান।
2. কমান্ড চালান:

atest

বর্তমান ডিরেক্টরির TEST_MAPPING ফাইলে কনফিগার করা সমস্ত প্রি-সাবমিট পরীক্ষা এবং এর মূল ডিরেক্টরি চালানো হয়। Atest পূর্ব জমা দেওয়ার জন্য দুটি পরীক্ষা সনাক্ত করবে এবং চালাবে (A এবং B)।

বর্তমান ওয়ার্কিং ডাইরেক্টরি (CWD) এবং প্যারেন্ট ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিতে প্রি-সাবমিট পরীক্ষা চালানোর এটি সবচেয়ে সহজ উপায়। Atest CWD এবং এর সমস্ত মূল ডিরেক্টরিতে TEST_MAPPING ফাইল সনাক্ত করবে এবং ব্যবহার করবে।

স্ট্রাকচার সোর্স কোড

নিম্নলিখিত উদাহরণটি দেখায় কিভাবে TEST_MAPPING ফাইলগুলি উৎস ট্রি জুড়ে কনফিগার করা যেতে পারে।

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING এর বিষয়বস্তু:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

টার্গেট ডিরেক্টরি নির্দিষ্ট করুন

আপনি সেই ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিতে পরীক্ষা চালানোর জন্য একটি লক্ষ্য ডিরেক্টরি নির্দিষ্ট করতে পারেন। নিম্নলিখিত কমান্ড দুটি পরীক্ষা চালাবে (A, B)।

atest --test-mapping src/project_1

পোস্ট সাবমিট পরীক্ষার নিয়ম চালান

আপনি src_path (CWD-তে ডিফল্ট) এবং এর মূল ডিরেক্টরিতে TEST_MAPPING-এ সংজ্ঞায়িত পোস্ট-সাবমিট পরীক্ষার নিয়মগুলি চালানোর জন্যও এই কমান্ডটি ব্যবহার করতে পারেন:

atest [--test-mapping] [src_path]:postsubmit

শুধুমাত্র এমন পরীক্ষা চালান যাতে কোনো ডিভাইসের প্রয়োজন হয় না

কোনো ডিভাইসের প্রয়োজন নেই এমন হোস্টের বিরুদ্ধে কনফিগার করা পরীক্ষা চালানোর জন্য আপনি Atest-এর জন্য --host বিকল্প ব্যবহার করতে পারেন। এই বিকল্পটি ছাড়া, Atest উভয় পরীক্ষাই চালাবে, যেগুলি ডিভাইসের প্রয়োজন এবং যেগুলি হোস্টে চলছে এবং কোনও ডিভাইসের প্রয়োজন নেই৷ পরীক্ষা দুটি পৃথক স্যুটে পরিচালিত হবে।

atest [--test-mapping] --host

পরীক্ষা গ্রুপ সনাক্ত করুন

আপনি Atest কমান্ডে পরীক্ষার গ্রুপগুলি নির্দিষ্ট করতে পারেন। নিম্নলিখিত কমান্ডটি src/project_1 ডিরেক্টরিতে ফাইলগুলির সাথে সম্পর্কিত সমস্ত পোস্টসাবমিট পরীক্ষা চালাবে, যেটিতে শুধুমাত্র একটি পরীক্ষা (C) রয়েছে।

অথবা আপনি গ্রুপ নির্বিশেষে সমস্ত পরীক্ষা চালানোর জন্য :all ব্যবহার করতে পারেন। নিম্নলিখিত কমান্ডটি চারটি পরীক্ষা চালায় (A, B, C, X):

atest --test-mapping src/project_1:all

সাবডিরেক্টরি অন্তর্ভুক্ত করুন

ডিফল্টরূপে, Atest-এর সাথে TEST_MAPPING-এ চলমান পরীক্ষাগুলি শুধুমাত্র CWD (বা প্রদত্ত ডিরেক্টরি) এবং এর মূল ডিরেক্টরিতে TEST_MAPPING ফাইলে কনফিগার করা প্রি-সাবমিট পরীক্ষা চালাবে। আপনি যদি সাব-ডিরেক্টরিগুলিতে সমস্ত TEST_MAPPING ফাইলে পরীক্ষা চালাতে চান, তবে সেই পরীক্ষাগুলিকে অন্তর্ভুক্ত করতে Atest-কে বাধ্য করতে --include-subdir বিকল্পটি ব্যবহার করুন।

atest --include-subdir

--include-subdir বিকল্প ছাড়া, Atest শুধুমাত্র পরীক্ষা A চালাবে --include-subdir বিকল্পের সাথে, Atest দুটি পরীক্ষা চালাবে (A, B)।

লাইন-স্তরের মন্তব্য সমর্থিত

আপনি একটি লাইন-স্তরের // -ফরম্যাট মন্তব্য যোগ করতে পারেন TEST_MAPPING ফাইলটি নিচের সেটিংটির বর্ণনা সহ। ATest এবং ট্রেড ফেডারেশন কোন মন্তব্য ছাড়াই TEST_MAPPING একটি বৈধ JSON ফর্ম্যাটে প্রিপ্রসেস করবে। JSON ফাইলটি পরিষ্কার এবং সহজে পড়ার জন্য, শুধুমাত্র লাইন-লেভেল // -ফর্ম্যাট মন্তব্য সমর্থিত।

উদাহরণ:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}