মডিউল কনফিগারেশনের সামগ্রিক কাঠামোটি সাধারণ ট্রেডফেড এক্সএমএল কনফিগারেশনের মতোই একটি প্যাটার্ন অনুসরণ করে, তবে এগুলো একটি স্যুটের অংশ হিসেবে চলার কারণে কিছু সীমাবদ্ধতা রয়েছে।
অনুমোদিত ট্যাগগুলির তালিকা
AndroidTest.xml অথবা আরও বিস্তৃতভাবে মডিউল কনফিগারেশনে শুধুমাত্র নিম্নলিখিত XML ট্যাগগুলো থাকতে পারে: target_preparer , multi_target_preparer , test এবং metrics_collector ।
যদিও তালিকাটি সীমাবদ্ধ মনে হতে পারে, এটি আপনাকে টেস্ট মডিউল সেটআপের প্রয়োজনীয়তা এবং কোন টেস্টটি চালাতে হবে তা সুনির্দিষ্টভাবে নির্ধারণ করতে সাহায্য করে।
দ্রষ্টব্য: বিভিন্ন ট্যাগ সম্পর্কে পুনরায় জানতে ট্রেডফেড এক্সএমএল কনফিগারেশন দেখুন।
build_provider বা result_reporter মতো অবজেক্টগুলোকে কোনো মডিউল কনফিগারেশনের ভেতর থেকে চালানোর চেষ্টা করা হলে একটি ConfigurationException থ্রো করবে। এর উদ্দেশ্য হলো, এই অবজেক্টগুলো মডিউলের ভেতর থেকে প্রকৃতপক্ষে কোনো কাজ করবে—এমন প্রত্যাশা এড়ানো।
মডিউল কনফিগারেশনের উদাহরণ
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
এই কনফিগারেশনটি এমন একটি পরীক্ষার বর্ণনা দেয় যার জন্য CtsGestureTestCases.apk ইনস্টল করা আবশ্যক এবং এটি android.gesture.cts প্যাকেজের বিরুদ্ধে একটি ইন্সট্রুমেন্টেশন চালাবে।
অন্তর্ভুক্তি ট্যাগ <include> এবং <template-include>
মডিউল কনফিগারেশনে <include> এবং <template-include> ব্যবহার নিরুৎসাহিত করা হয়। এগুলো প্রত্যাশিতভাবে কাজ করবেই এমন কোনো নিশ্চয়তা নেই।
metrics_collector ট্যাগের জন্য বিশেষ ক্ষেত্র
মডিউলটির জন্য কোনো নির্দিষ্ট ফাইল বা ডিরেক্টরি পুল ও লগ করার উদ্দেশ্যে, metrics_collector শুধুমাত্র FilePullerLogCollector ক্লাসের মধ্যেই সীমাবদ্ধ। আপনি যদি কোনো নির্দিষ্ট স্থানে লগ রেখে যান এবং সেগুলো স্বয়ংক্রিয়ভাবে পুনরুদ্ধার করতে চান, তবে এটি কার্যকর।
উদাহরণ কনফিগারেশন:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
বিল্ডের তথ্য বা ডাউনলোডের ব্যাপারে কী হবে?
অনুমোদিত ট্যাগগুলোর সংজ্ঞা থেকে এমন ভুল ধারণা হতে পারে যে, একটি মডিউল কোনো বিল্ড তথ্য পাবে না। এটি সত্য নয় ।
বিল্ড সংক্রান্ত তথ্য স্যুট-স্তরের সেটআপ থেকে সরবরাহ করা হয় এবং স্যুটের সমস্ত মডিউলের মধ্যে তা শেয়ার করা হবে। এর ফলে স্যুটের জন্য একটিমাত্র শীর্ষ-স্তরের সেটআপ তৈরি করা যায়, যার মাধ্যমে স্যুটের অন্তর্ভুক্ত সমস্ত মডিউল চালানো সম্ভব হয়।
উদাহরণস্বরূপ, প্রতিটি কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) মডিউল আলাদাভাবে ডিভাইসের তথ্য, প্রকার ইত্যাদি জিজ্ঞাসা করার পরিবর্তে, CTS স্যুট-স্তরের সেটআপ ( cts.xml ) এটি একবার করে এবং প্রতিটি মডিউল অনুরোধ করলে সেই তথ্য পেয়ে যাবে।
একটি মডিউলের অবজেক্টগুলো যাতে বিল্ড তথ্য পেতে পারে, তার জন্য তাদের সাধারণ ট্রেডফেড কনফিগারেশনের মতোই IBuildInfo গ্রহণ করার জন্য IBuildReceiver ইন্টারফেসটি ইমপ্লিমেন্ট করতে হবে। আরও বিস্তারিত জানতে ডিভাইস দিয়ে টেস্টিং দেখুন।
মেটাডেটা ক্ষেত্র
বিপুল সংখ্যক টেস্ট মডিউলে কিছু metadata স্পেসিফিকেশন অন্তর্ভুক্ত থাকে, যেগুলোর প্রতিটিরই একটি স্বতন্ত্র লক্ষ্য রয়েছে।
উদাহরণ:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
উপাদান
component মেটাডেটা সেই সাধারণ অ্যান্ড্রয়েড কম্পোনেন্টটির বর্ণনা দেয়, যা মডিউলটি পরীক্ষা করতে চায়। পরীক্ষা সম্পাদনের উপর এর কোনো সরাসরি প্রভাব নেই; এটি মূলত সাংগঠনিক উদ্দেশ্যে ব্যবহৃত হয়।
CTS-এর জন্য অনুমোদিত কম্পোনেন্টগুলোর হালনাগাদ তালিকা CtsConfigLoadingTest- এ পাওয়া যায়। কোনো CTS মডিউলে অস্তিত্বহীন কোনো কম্পোনেন্ট যোগ করা হলে এই টেস্টটি presubmit পর্যায়ে ব্যর্থ হয়।
আপনি module-metadata-include-filter এবং module-metadata-exclude-filter ব্যবহার করে কম্পোনেন্টের উপর ভিত্তি করে একটি স্যুট রান ফিল্টার করতে পারেন।
উদাহরণ:
--module-metadata-include-filter component framework
এই উদাহরণটি শুধুমাত্র framework কম্পোনেন্ট দ্বারা টীকাযুক্ত টেস্ট মডিউলটি চালায়।
প্যারামিটার
parameter মেটাডেটা তথ্যমূলক এবং এটি টেস্ট সম্পাদনের উপর প্রভাব ফেলে। এটি নির্দিষ্ট করে যে টেস্ট মডিউলটি কোন অ্যান্ড্রয়েড মোডে প্রযোজ্য হবে। এক্ষেত্রে, মোডগুলো উচ্চ-স্তরের অ্যান্ড্রয়েড মোডগুলোর মধ্যে সীমাবদ্ধ, যেমন instant apps , secondary users বা different abis ।
সুইটটি চলার সময়, যদি মোডটি টেস্টের জন্য প্রযোজ্য হয়, তবে সেই মোডের উপর ভিত্তি করে টেস্ট মডিউলের একাধিক সংস্করণ তৈরি করা হয়। প্রতিটি সংস্করণ একই ধরনের টেস্ট চালায়, কিন্তু ভিন্ন ভিন্ন মোডে।
-
instant_app: পরীক্ষাগুলোর এমন একটি সংস্করণ তৈরি করুন যা APK ফাইলগুলোকে ইনস্ট্যান্ট অ্যাপ হিসেবে ইনস্টল করে। -
multi_abi: ডিভাইস দ্বারা সমর্থিত প্রতিটি ABI-এর জন্য পরীক্ষাগুলির একটি ভিন্ন সংস্করণ তৈরি করুন। -
secondary_user: টেস্টগুলোর এমন একটি সংস্করণ তৈরি করুন যা APK ইনস্টল করে এবং সেকেন্ডারি ইউজার হিসেবে টেস্টগুলো চালায়।
পারফরম্যান্স টেস্ট মডিউলগুলির জন্য মেট্রিক সংগ্রহ এবং পোস্ট-প্রসেসিং
পারফরম্যান্স টেস্ট মডিউলগুলোর জন্য মডিউল-স্তরের metrics_collector এবং metric_post_processor ব্যবহার করা যায়, কারণ এগুলো পারফরম্যান্স টেস্টের জন্য অপরিহার্য। মডিউল-স্তরের মেট্রিক কালেক্টর এবং পোস্ট-প্রসেসরগুলো মডিউল-নির্দিষ্ট হতে পারে। শীর্ষ-স্তর এবং মডিউল-স্তর উভয় ক্ষেত্রেই পোস্ট-প্রসেসর নির্দিষ্ট করার সুপারিশ করা হয় না।
একটি পারফরম্যান্স টেস্ট মডিউল কনফিগারেশনে অবশ্যই ' test-type মেটাডেটা অন্তর্ভুক্ত থাকতে হবে যার ভ্যালু হবে performance , যেমন: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> এটি ছাড়া, যদি কোনো টেস্ট কনফিগারেশনে FilePullerLogCollector ব্যতীত অন্য কোনো metric_collector অথবা কোনো metric_post_processor অন্তর্ভুক্ত থাকে, তাহলে টেস্টটি presubmit-এ ব্যর্থ হবে।
পারফরম্যান্স টেস্ট মডিউল কনফিগারেশনের উদাহরণ:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>