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

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

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

কাস্টম টেস্টিং করতে বা অ্যান্ড্রয়েড কম্প্যাটিবিলিটি টেস্ট স্যুট (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 সাফিক্স যুক্ত হবে, যেমন এই ক্ষেত্রে, তৈরি হওয়া টেস্ট এপিকে-টির নাম হবে HelloWorldTests.apk । এছাড়াও, এটি আপনার মডিউলের জন্য একটি make টার্গেট নামও নির্ধারণ করে দেয়, যাতে আপনি make [options] <HelloWorldTests> ব্যবহার করে আপনার টেস্ট মডিউল এবং এর সমস্ত ডিপেন্ডেন্সি বিল্ড করতে পারেন।

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

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

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

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

    certificate: "platform",

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

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

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

    test_suites: ["device-tests"],

test_suites সেটিংটি ট্রেড ফেডারেশন টেস্ট হারনেস দ্বারা টেস্টটিকে সহজে খুঁজে পাওয়ার যোগ্য করে তোলে। এখানে 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` যোগ করার নির্দেশ দেয়। যখন ট্রেড ফেডারেশন টেস্ট কনফিগটি রান করে, তখন যদি ro.product.first_api_level এর `device` প্রপার্টির মান test_min_api_level এর চেয়ে কম হয়, তাহলে টেস্টটি স্কিপ করা হবে।