সহজ বিল্ড কনফিগারেশন

প্রতিটি নতুন টেস্ট মডিউলে মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা ও প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে নির্দেশ দেওয়ার জন্য একটি কনফিগারেশন ফাইল থাকতে হবে। Android এখন আরও সহজ টেস্ট কনফিগারেশনের জন্য Soong বিল্ড সিস্টেম ব্যবহার করে।

Soong, Blueprint বা .bp ফাইল ব্যবহার করে, যা JSON-এর মতো সহজ ঘোষণামূলক মডিউল তৈরির বিবরণ। এই ফর্ম্যাটটি আগের রিলিজগুলিতে ব্যবহৃত Make-ভিত্তিক সিস্টেমের পরিবর্তে ব্যবহার করা হয়। সম্পূর্ণ বিবরণের জন্য কন্টিনিউয়াস ইন্টিগ্রেশন ড্যাশবোর্ডে গিয়ে Soong রেফারেন্স ফাইল দেখুন।

কাস্টম টেস্টিং বা Android কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) ব্যবহার করতে, এর পরিবর্তে জটিল টেস্ট কনফিগারেশন সম্পর্কিত নির্দেশাবলী অনুসরণ করুন।

উদাহরণ

নিচে দেওয়া এন্ট্রি এই উদাহরণ ব্লুপ্রিন্ট কনফিগারেশন ফাইল থেকে নেওয়া হয়েছে: /platform_testing/tests/example/instrumentation/Android.bp

সুবিধার জন্য এখানে একটি স্ন্যাপশট অন্তর্ভুক্ত করা হয়েছে:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

মনে রাখবেন, শুরুতে android_test ঘোষণা থেকে বোঝা যায় যে এটি একটি টেস্ট। android_app যোগ করলে, এর পরিবর্তে এটি একটি বিল্ড প্যাকেজ বলে ইঙ্গিত করা হবে।

সেটিংস

নিচে উল্লেখ করা সেটিংসের ব্যাখ্যা প্রয়োজন:

    name: "HelloWorldTests",

android_test মডিউলের ধরন নির্দিষ্ট করা থাকলে name সেটিং প্রয়োজন (ব্লকের শুরুতে)। এটি আপনার মডিউলের একটি নাম দেয় এবং এর ফলে APK-এর নাম একই হবে এবং একটি .apk প্রত্যয় সহ, যেমন এই ক্ষেত্রে, ফলাফল টেস্ট apk-এর নাম HelloWorldTests.apk হিসাবে রাখা হয়েছে। এছাড়াও, এটি আপনার মডিউলের জন্য একটি মেক টার্গেট নামও সংজ্ঞায়িত করে, যাতে আপনি make [options] <HelloWorldTests> ব্যবহার করে আপনার টেস্ট মডিউল এবং এর সমস্ত নির্ভরতা তৈরি করতে পারেন।

    static_libs: ["androidx.test.runner"],

static_libs সেটিং বিল্ড সিস্টেমকে নির্দেশ দেয় যাতে বর্তমান মডিউলের apk-তে নাম দেওয়া মডিউলের কন্টেন্ট অন্তর্ভুক্ত করা হয়। এর অর্থ হল যে নামযুক্ত প্রতিটি মডিউল থেকে একটি .jar ফাইল তৈরি হওয়ার কথা এবং এর কন্টেন্ট কম্পাইল করার সময় ক্লাসপাথ রেফারেন্স সমাধান করার জন্য ব্যবহার করা হবে, পাশাপাশি ফাইনাল apk-তে অন্তর্ভুক্ত করা হবে।

androidx.test.runner মডিউল হল AndroidX Test Runner লাইব্রেরির জন্য আগে থেকে তৈরি করা, যার মধ্যে টেস্ট রানার AndroidJUnitRunner অন্তর্ভুক্ত। AndroidJUnitRunner JUnit4 টেস্টিং ফ্রেমওয়ার্ক সাপোর্ট করে এবং Android 10-এ InstrumentationTestRunner-এর পরিবর্তে ব্যবহার করা হয়। Android-এ অ্যাপ পরীক্ষা করা লিঙ্কে গিয়ে Android অ্যাপ পরীক্ষা করা সম্পর্কে আরও জানুন।

আপনি নতুন ইন্সট্রুমেন্টেশন মডিউল তৈরি করলে, আপনাকে সবসময় androidx.test.runner লাইব্রেরিকে টেস্ট রানার হিসেবে ব্যবহার করে শুরু করতে হবে। এছাড়াও, প্ল্যাটফর্ম সোর্স ট্রি-তে ub-uiautomator, mockito-target, easymock এবং আরও অনেক কিছুর মতো অন্যান্য দরকারী টেস্টিং ফ্রেমওয়ার্ক অন্তর্ভুক্ত থাকে।

    certificate: "platform",

certificate সেটিং, বিল্ড সিস্টেমকে নির্দেশ দেয় যে কোর প্ল্যাটফর্মের মতো একই সার্টিফিকেট দিয়ে apk সাইন করতে হবে। আপনার টেস্টে যদি কোনও সিগনেচার প্রোটেক্টেড অনুমতি বা API ব্যবহার করা হয়, তাহলে এটি প্রয়োজন। মনে রাখবেন যে এটি প্ল্যাটফর্মের ক্রমাগত পরীক্ষার জন্য উপযুক্ত, তবে CTS টেস্ট মডিউলে ব্যবহার করা উচিত নয়। মনে রাখবেন, এই উদাহরণে শুধুমাত্র বোঝানোর উদ্দেশ্যে এই সার্টিফিকেট সেটিং ব্যবহার করা হয়েছে: এই উদাহরণের টেস্ট কোডের জন্য আসলে বিশেষ প্ল্যাটফর্ম সার্টিফিকেটের মাধ্যমে টেস্ট APK-তে সই করার প্রয়োজন নেই।

আপনি যদি সিস্টেম সার্ভারের বাইরে থাকা কম্পোনেন্টের জন্য ইন্সট্রুমেন্টেশন লেখেন, অর্থাৎ, এটি কম-বেশি সাধারণ অ্যাপ apk-এর মতো প্যাকেজ করা হয়, তবে এটি সিস্টেম ইমেজে তৈরি করা হয় এবং এটি একটি বিশেষ সুবিধাপ্রাপ্ত অ্যাপ হতে পারে, সম্ভবত আপনার ইন্সট্রুমেন্টেশন আপনার কম্পোনেন্টের অ্যাপ প্যাকেজকে (ম্যানিফেস্ট সম্পর্কে নিচের বিভাগ দেখুন) টার্গেট করবে। এই ক্ষেত্রে, আপনার অ্যাপ্লিকেশন makefile-এর নিজস্ব certificate সেটিং থাকতে পারে এবং আপনার ইন্সট্রুমেন্টেশন মডিউলে একই সেটিং থাকতে হবে। এর কারণ হল, পরীক্ষা করা হচ্ছে এমন অ্যাপে আপনার ইনস্ট্রুমেন্টেশনকে টার্গেট করতে, আপনার টেস্ট APK ও অ্যাপ APK একই সার্টিফিকেট দিয়ে সাইন করতে হবে।

অন্যান্য ক্ষেত্রে, আপনার এই সেটিংয়ের প্রয়োজনই নেই: বিল্ড সিস্টেম বিল্ড ভ্যারিয়েন্টের উপর ভিত্তি করে ডিফল্ট বিল্ট-ইন সার্টিফিকেট দিয়ে এটি সাইন করে দেবে এবং এটিকে সাধারণত dev-keys বলা হয়।

    test_suites: ["device-tests"],

test_suites সেটিং Trade Federation টেস্ট হারনেসের মাধ্যমে টেস্টকে সহজে খুঁজে পাওয়ার উপযুক্ত করে তোলে। এখানে CTS-এর মতো অন্যান্য স্যুট যোগ করা যেতে পারে যাতে এই পরীক্ষা শেয়ার করা যায়।

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

ঐচ্ছিক সেটিংস

নিচে উল্লেখ করা ঐচ্ছিক সেটিংসের ব্যাখ্যা দেওয়া হল:

    test_config: "path/to/hello_world_test.xml"

test_config সেটিং, বিল্ড সিস্টেমকে নির্দেশ দেয় যে আপনার টেস্ট টার্গেটের একটি নির্দিষ্ট কনফিগারেশন প্রয়োজন। ডিফল্ট হিসেবে, Android.bp-এর পাশে থাকা AndroidTest.xml কনফিগারেশনের সাথে যুক্ত থাকে।

    auto_gen_config: true

auto_gen_config সেটিং থেকে বোঝা যায় যে টেস্ট কনফিগারেশন অটোমেটিক তৈরি করা হবে কিনা । Android.bp-এর পাশে AndroidTest.xml না থাকলে, এই অ্যাট্রিবিউটকে স্পষ্টভাবে'true' হিসেবে সেট করার প্রয়োজন নেই।

    require_root: true

require_root সেটিং, বিল্ড সিস্টেমকে অটোমেটিক জেনারেট করা টেস্ট কনফিগারেশনে RootTargetPreparer যোগ করার নির্দেশ দেয়। এটি রুট অনুমতির সাথে টেস্ট রান করার গ্যারান্টি দেয়।

    test_min_api_level: 29

test_min_api_level সেটিং, অটোমেটিক তৈরি হওয়া টেস্ট কনফিগে MinApiLevelModuleController যোগ করার জন্য বিল্ড সিস্টেমকে নির্দেশ দেয়। Trade Federation টেস্ট কনফিগারেশন রান করলে, ডিভাইসের প্রপার্টি ro.product.first_api_level < test_min_api_level হলে টেস্টটি এড়িয়ে যাওয়া হবে।