এটি টেস্ট ম্যাপিং-এর একটি সংক্ষিপ্ত পরিচিতি এবং অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট (AOSP)-এ কীভাবে টেস্ট কনফিগার করা শুরু করতে হয় তার ব্যাখ্যা।
টেস্ট ম্যাপিং সম্পর্কে
টেস্ট ম্যাপিং হলো একটি গেরিট-ভিত্তিক পদ্ধতি, যা ডেভেলপারদের সরাসরি অ্যান্ড্রয়েড সোর্স ট্রি-তে প্রিসাবমিট ও পোস্টসাবমিট টেস্ট রুল তৈরি করতে দেয় এবং কোন ব্রাঞ্চ ও ডিভাইস পরীক্ষা করা হবে, সেই সিদ্ধান্ত টেস্ট ইনফ্রাস্ট্রাকচারের উপর ছেড়ে দেয়। টেস্ট ম্যাপিং ডেফিনিশনগুলো হলো TEST_MAPPING নামের JSON ফাইল, যা আপনি যেকোনো সোর্স ডিরেক্টরিতে রাখতে পারেন।
Atest সংশ্লিষ্ট ডিরেক্টরিগুলিতে প্রিসাবমিট টেস্ট চালানোর জন্য TEST_MAPPING ফাইলগুলি ব্যবহার করতে পারে। টেস্ট ম্যাপিংয়ের মাধ্যমে, আপনি অ্যান্ড্রয়েড সোর্স ট্রিতে সামান্য পরিবর্তন করেই প্রিসাবমিট চেকগুলিতে একই টেস্ট সেট যোগ করতে পারেন।
এই উদাহরণগুলো দেখুন:
services.coreএর জন্যTEST_MAPPINGএ প্রিসাবমিট টেস্ট যোগ করুনimport ব্যবহার করে
tools/dexterজন্যTEST_MAPPINGএ presubmit টেস্ট যোগ করুন।
পরীক্ষা সম্পাদন ও ফলাফল প্রতিবেদনের জন্য টেস্ট ম্যাপিং ট্রেড ফেডারেশন (টিএফ) টেস্ট হারনেসের উপর নির্ভর করে।
পরীক্ষার দলগুলি সংজ্ঞায়িত করুন
টেস্ট ম্যাপিং একটি টেস্ট গ্রুপের অধীনে টেস্টগুলোকে একত্রিত করে। একটি টেস্ট গ্রুপের নাম যেকোনো স্ট্রিং হতে পারে। উদাহরণস্বরূপ, পরিবর্তনগুলো যাচাই করার সময় চালানোর জন্য টেস্টের একটি গ্রুপের নাম হতে পারে ‘presubmit’ । এবং পরিবর্তনগুলো মার্জ করার পরে বিল্ডগুলো যাচাই করতে ব্যবহৃত টেস্টগুলোর নাম হতে পারে ‘postsubmit’ ।
প্যাকেজ বিল্ড স্ক্রিপ্ট নিয়ম
ট্রেড ফেডারেশন টেস্ট হারনেস দ্বারা কোনো নির্দিষ্ট বিল্ডের জন্য টেস্ট মডিউল চালানোর জন্য, এই মডিউলগুলিতে অবশ্যই Soong- এর জন্য test_suites অথবা Make-এর জন্য LOCAL_COMPATIBILITY_SUITE এই দুটি স্যুটের মধ্যে যেকোনো একটিতে সেট করা থাকতে হবে:
-
general-testsহলো সেইসব পরীক্ষার জন্য যা ডিভাইস-নির্দিষ্ট ক্ষমতার উপর নির্ভর করে না (যেমন বিক্রেতা-নির্দিষ্ট হার্ডওয়্যার যা বেশিরভাগ ডিভাইসে থাকে না)। বেশিরভাগ পরীক্ষাইgeneral-testsস্যুটের অন্তর্ভুক্ত হওয়া উচিত, এমনকি যদি সেগুলি কোনো একটি ABI বা বিটনেস বা HWASan-এর মতো হার্ডওয়্যার বৈশিষ্ট্যের জন্য নির্দিষ্ট হয় (প্রতিটি ABI-এর জন্য একটি পৃথকtest_suitesটার্গেট রয়েছে), এবং এমনকি যদি সেগুলি কোনো ডিভাইসে চালাতে হয়। -
device-testsহলো সেইসব টেস্টের জন্য যা ডিভাইস-নির্দিষ্ট সক্ষমতার উপর নির্ভর করে। সাধারণত এই টেস্টগুলোvendor/অধীনে পাওয়া যায়। ডিভাইস-নির্দিষ্ট বলতে শুধুমাত্র সেইসব সক্ষমতাকে বোঝায় যা একটি ডিভাইসের জন্য অনন্য, তাই এটি JUnit টেস্টের পাশাপাশি GTest টেস্টের ক্ষেত্রেও প্রযোজ্য (যেগুলোকে সাধারণত ABI-নির্দিষ্ট হলেওgeneral-testsহিসেবে চিহ্নিত করা উচিত)।
উদাহরণ:
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": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
বৈশিষ্ট্য সেট করুন
উদাহরণটিতে , presubmit এবং postsubmit হলো প্রতিটি টেস্ট গ্রুপের নাম। টেস্ট গ্রুপ সম্পর্কে আরও তথ্যের জন্য ‘টেস্ট গ্রুপ সংজ্ঞায়িত করুন’ দেখুন।
আপনি name অ্যাট্রিবিউটের ভ্যালুতে টেস্ট মডিউলের নাম অথবা ট্রেড ফেডারেশন ইন্টিগ্রেশন টেস্টের নাম (যেমন, টেস্ট XML ফাইলের রিসোর্স পাথ, uiautomator/uiautomator-demo ) সেট করতে পারেন। মনে রাখবেন যে name ফিল্ডে ক্লাসের name বা টেস্ট মেথডের name ব্যবহার করা যাবে না। চালানোর জন্য টেস্টের সংখ্যা সীমিত করতে include-filter এর মতো অপশন ব্যবহার করুন। include-filter নমুনা ব্যবহার দেখুন।
একটি টেস্টের host সেটিং নির্দেশ করে যে টেস্টটি হোস্টে চলমান একটি ডিভাইসবিহীন টেস্ট কিনা। এর ডিফল্ট মান হলো false , যার অর্থ টেস্টটি চালানোর জন্য একটি ডিভাইসের প্রয়োজন। সমর্থিত টেস্টের ধরনগুলো হলো GTest বাইনারির জন্য HostGTest এবং JUnit টেস্টের জন্য HostTest ।
` file_patterns অ্যাট্রিবিউটটি আপনাকে যেকোনো সোর্স কোড ফাইলের রিলেটিভ পাথ (যে ডিরেক্টরিতে ` TEST_MAPPING ফাইলটি রয়েছে তার সাপেক্ষে) মেলানোর জন্য রেগুলার এক্সপ্রেশন স্ট্রিং-এর একটি তালিকা সেট করতে দেয়। উদাহরণস্বরূপ , CtsWindowManagerDeviceTestCases টেস্টটি `presubmit` মোডে কেবল তখনই রান করে যখন একটি জাভা ফাইল Window বা Activity দিয়ে শুরু হয়, যা TEST_MAPPING ফাইল বা তার যেকোনো সাবডিরেক্টরির একই ডিরেক্টরিতে বিদ্যমান থাকে। ব্যাকস্ল্যাশ (\) চিহ্নগুলোকে এস্কেপ করতে হবে, কারণ সেগুলো একটি JSON ফাইলের মধ্যে রয়েছে।
imports অ্যাট্রিবিউটটি আপনাকে কন্টেন্ট কপি না করেই অন্যান্য TEST_MAPPING ফাইলে টেস্ট অন্তর্ভুক্ত করার সুযোগ দেয়। ইম্পোর্ট করা পাথের প্যারেন্ট ডিরেক্টরিতে থাকা TEST_MAPPING ফাইলগুলোও এর অন্তর্ভুক্ত হয়। টেস্ট ম্যাপিং নেস্টেড ইম্পোর্ট সমর্থন করে; এর মানে হলো দুটি TEST_MAPPING ফাইল একে অপরকে ইম্পোর্ট করতে পারে এবং টেস্ট ম্যাপিং অন্তর্ভুক্ত টেস্টগুলোকে মার্জ করতে পারে।
options অ্যাট্রিবিউটে অতিরিক্ত ট্রেডফেড কমান্ড লাইন অপশনগুলো থাকে।
কোনো নির্দিষ্ট পরীক্ষার জন্য উপলব্ধ বিকল্পগুলির একটি সম্পূর্ণ তালিকা পেতে, চালান:
tradefed.sh run commandAndExit [test_module] --help
অপশন কীভাবে কাজ করে সে সম্পর্কে আরও বিস্তারিত জানতে ট্রেডফেডে অপশন হ্যান্ডলিং দেখুন।
Atest দিয়ে পরীক্ষা চালান
স্থানীয়ভাবে প্রিসাবমিট টেস্ট নিয়মগুলি কার্যকর করতে:
-
TEST_MAPPINGফাইলটি যে ডিরেক্টরিতে রয়েছে, সেখানে যান। কমান্ডটি চালান:
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 ডিরেক্টরিতে থাকা ফাইলগুলির সাথে সম্পর্কিত সমস্ত postsubmit টেস্ট চালায়, যেটিতে শুধুমাত্র একটি টেস্ট (C) রয়েছে।
অথবা আপনি গ্রুপ নির্বিশেষে সমস্ত পরীক্ষা চালানোর জন্য :all ব্যবহার করতে পারেন। নিম্নলিখিত কমান্ডটি চারটি পরীক্ষা (A, B, C, X) চালায়:
atest --test-mapping src/project_1:all
সাবডিরেক্টরি অন্তর্ভুক্ত করুন
ডিফল্টরূপে, Atest দিয়ে TEST_MAPPING এ টেস্ট চালালে শুধুমাত্র CWD (বা প্রদত্ত ডিরেক্টরি) এবং এর প্যারেন্ট ডিরেক্টরিগুলোতে থাকা TEST_MAPPING ফাইলে কনফিগার করা প্রিসাবমিট টেস্টগুলোই রান হয়। আপনি যদি সাবডিরেক্টরিগুলোর সমস্ত TEST_MAPPING ফাইলের টেস্ট রান করতে চান, তাহলে --include-subdir অপশনটি ব্যবহার করুন, যা Atest-কে সেই টেস্টগুলোও অন্তর্ভুক্ত করতে বাধ্য করবে।
atest --include-subdir
--include-subdir অপশনটি ছাড়া, Atest শুধুমাত্র টেস্ট A চালায়। --include-subdir অপশনটি ব্যবহার করলে, Atest দুটি টেস্ট (A, B) চালায়।
লাইন-স্তরের মন্তব্য সমর্থিত
পরবর্তী সেটিংটির বর্ণনা দিয়ে TEST_MAPPING ফাইলটিকে আরও বিশদ করার জন্য আপনি একটি লাইন-লেভেল // ফরম্যাট কমেন্ট যোগ করতে পারেন। ATest এবং Trade Federation কমেন্ট ছাড়া TEST_MAPPING একটি বৈধ JSON ফরম্যাটে প্রি-প্রসেস করে। JSON ফাইলটিকে পরিচ্ছন্ন রাখার জন্য, শুধুমাত্র লাইন-লেভেল // ফরম্যাট কমেন্ট সমর্থিত।
উদাহরণ:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}