একটি অ্যাপের উদাহরণ টার্গেট করুন

এই ধরণের ইন্সট্রুমেন্টেশন টেস্ট নিয়মিত অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলিকে লক্ষ্য করে করা পরীক্ষাগুলির থেকে খুব বেশি আলাদা নয়। এটি লক্ষণীয় যে যে টেস্ট অ্যাপ্লিকেশনটিতে ইন্সট্রুমেন্টেশন অন্তর্ভুক্ত ছিল সেটিকে এটি যে অ্যাপ্লিকেশনটিকে লক্ষ্য করে তৈরি করছে তার সাথে একই সার্টিফিকেট দিয়ে স্বাক্ষরিত হতে হবে।

মনে রাখবেন যে এই নির্দেশিকাটি ধরে নিচ্ছে যে প্ল্যাটফর্ম সোর্স ট্রি ওয়ার্কফ্লো সম্পর্কে আপনার ইতিমধ্যেই কিছু জ্ঞান আছে। যদি না থাকে, তাহলে অনুগ্রহ করে Requirements দেখুন। এখানে যে উদাহরণটি দেওয়া হয়েছে তা হল নিজস্ব টেস্ট অ্যাপ্লিকেশন প্যাকেজে টার্গেট প্যাকেজ সেট করে একটি নতুন ইন্সট্রুমেন্টেশন টেস্ট লেখা। যদি আপনি ধারণাটির সাথে অপরিচিত থাকেন, তাহলে অনুগ্রহ করে প্ল্যাটফর্ম টেস্টিং ভূমিকাটি পড়ুন।

এই নির্দেশিকাটি নমুনা হিসেবে নিম্নলিখিত পরীক্ষাটি ব্যবহার করে:

  • ফ্রেমওয়ার্ক/বেস/প্যাকেজ/শেল/পরীক্ষা

এগিয়ে যাওয়ার আগে মোটামুটি ধারণা পেতে প্রথমে কোডটি ব্রাউজ করার পরামর্শ দেওয়া হচ্ছে।

উৎসের অবস্থান নির্ধারণ করুন

যেহেতু ইন্সট্রুমেন্টেশন পরীক্ষাটি একটি অ্যাপ্লিকেশনকে লক্ষ্য করে তৈরি করা হবে, তাই নিয়ম হল প্ল্যাটফর্ম সোর্স ট্রিতে আপনার কম্পোনেন্ট সোর্স ডিরেক্টরির রুটের নীচে একটি tests ডিরেক্টরিতে টেস্ট সোর্স কোড স্থাপন করা।

স্ব-উপকরণ পরীক্ষার জন্য এন্ড-টু-এন্ড উদাহরণে উৎস অবস্থান সম্পর্কে আরও আলোচনা দেখুন।

ম্যানিফেস্ট ফাইল

একটি সাধারণ অ্যাপ্লিকেশনের মতো, প্রতিটি ইন্সট্রুমেন্টেশন টেস্ট মডিউলের একটি ম্যানিফেস্ট ফাইলের প্রয়োজন হয়। যদি আপনি ফাইলটির নাম AndroidManifest.xml রাখেন এবং আপনার টেস্ট tmodule-এর জন্য Android.mk এর পাশে এটি প্রদান করেন, তাহলে এটি স্বয়ংক্রিয়ভাবে BUILD_PACKAGE কোর মেকফাইলে অন্তর্ভুক্ত হয়ে যাবে।

আরও এগিয়ে যাওয়ার আগে, প্রথমে অ্যাপ ম্যানিফেস্ট ওভারভিউটি দেখে নেওয়া অত্যন্ত বাঞ্ছনীয়।

এটি একটি ম্যানিফেস্ট ফাইলের মৌলিক উপাদান এবং তাদের কার্যকারিতা সম্পর্কে একটি সারসংক্ষেপ প্রদান করে।

নমুনা জেরিট পরিবর্তনের জন্য ম্যানিফেস্ট ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: https://android.googlesource.com/platform/frameworks/base/+/android16-qpr1-release/packages/Shell/tests/AndroidManifest.xml

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

ম্যানিফেস্ট ফাইলের কিছু নির্বাচিত মন্তব্য:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package অ্যাট্রিবিউট হল অ্যাপ্লিকেশন প্যাকেজের নাম: এটি হল অনন্য শনাক্তকারী যা অ্যান্ড্রয়েড অ্যাপ্লিকেশন ফ্রেমওয়ার্ক একটি অ্যাপ্লিকেশন সনাক্ত করতে ব্যবহার করে (অথবা এই প্রসঙ্গে: আপনার পরীক্ষামূলক অ্যাপ্লিকেশন)। সিস্টেমের প্রতিটি ব্যবহারকারী সেই প্যাকেজ নামের সাথে কেবল একটি অ্যাপ্লিকেশন ইনস্টল করতে পারে।

যেহেতু এটি একটি পরীক্ষামূলক অ্যাপ্লিকেশন প্যাকেজ, পরীক্ষার অধীনে থাকা অ্যাপ্লিকেশন প্যাকেজ থেকে স্বাধীন, তাই একটি ভিন্ন প্যাকেজ নাম ব্যবহার করতে হবে: একটি সাধারণ নিয়ম হল একটি প্রত্যয় .test যোগ করা।

তদুপরি, এই package অ্যাট্রিবিউটটি ComponentName#getPackageName() যা ফেরত দেয় তার মতোই, এবং আপনি adb shell মাধ্যমে বিভিন্ন pm সাব কমান্ডের সাথে ইন্টারঅ্যাক্ট করতেও এটি ব্যবহার করবেন।

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

<uses-library android:name="android.test.runner" />

এটি সমস্ত ইন্সট্রুমেন্টেশন পরীক্ষার জন্য প্রয়োজনীয় কারণ সম্পর্কিত ক্লাসগুলি একটি পৃথক ফ্রেমওয়ার্ক জার লাইব্রেরি ফাইলে প্যাকেজ করা হয়, তাই অ্যাপ্লিকেশন ফ্রেমওয়ার্ক দ্বারা টেস্ট প্যাকেজটি আহ্বান করা হলে অতিরিক্ত ক্লাসপাথ এন্ট্রি প্রয়োজন হয়।

android:targetPackage="com.android.shell"

এটি ইন্সট্রুমেন্টেশনের টার্গেট প্যাকেজটিকে com.android.shell এ সেট করে। যখন am instrument কমান্ডের মাধ্যমে ইন্সট্রুমেন্টেশনটি চালু করা হয়, তখন ফ্রেমওয়ার্কটি com.android.shell প্রক্রিয়াটি পুনরায় চালু করে এবং পরীক্ষা সম্পাদনের জন্য প্রক্রিয়াটিতে ইন্সট্রুমেন্টেশন কোড ইনজেক্ট করে। এর অর্থ হল পরীক্ষার কোডটি পরীক্ষার অধীনে অ্যাপ্লিকেশনে চলমান সমস্ত ক্লাস ইনস্ট্যান্সে অ্যাক্সেস পাবে এবং পরীক্ষার হুকের উপর নির্ভর করে অবস্থা নিয়ন্ত্রণ করতে সক্ষম হতে পারে।

সহজ কনফিগারেশন ফাইল

প্রতিটি নতুন পরীক্ষা মডিউলে অবশ্যই একটি কনফিগারেশন ফাইল থাকতে হবে যা মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেম পরিচালনা করবে। বেশিরভাগ ক্ষেত্রে, Soong-ভিত্তিক, ব্লুপ্রিন্ট ফাইল বিকল্পটি যথেষ্ট। বিস্তারিত জানার জন্য Simple Test Configuration দেখুন।

জটিল কনফিগারেশন ফাইল

আরও জটিল পরীক্ষার জন্য, আপনাকে অ্যান্ড্রয়েডের টেস্ট হার্নেস, ট্রেড ফেডারেশনের জন্য একটি টেস্ট কনফিগারেশন ফাইলও লিখতে হবে।

পরীক্ষার কনফিগারেশন পরীক্ষা শ্রেণী সরবরাহের জন্য বিশেষ ডিভাইস সেটআপ বিকল্প এবং ডিফল্ট আর্গুমেন্ট নির্দিষ্ট করতে পারে।

নমুনা জেরিট পরিবর্তনের জন্য কনফিগ ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: frameworks/base/packages/Shell/tests/AndroidTest.xml

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

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>

পরীক্ষা কনফিগারেশন ফাইলের কিছু নির্বাচিত মন্তব্য:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

এটি ট্রেড ফেডারেশনকে একটি নির্দিষ্ট target_preparer ব্যবহার করে টার্গেট ডিভাইসে ShellTests.apk ইনস্টল করতে বলে। ট্রেড ফেডারেশনে ডেভেলপারদের জন্য অনেক টার্গেট প্রিপারার উপলব্ধ রয়েছে এবং পরীক্ষা সম্পাদনের আগে ডিভাইসটি সঠিকভাবে সেটআপ করা হয়েছে কিনা তা নিশ্চিত করতে এগুলি ব্যবহার করা যেতে পারে।

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

এটি পরীক্ষা চালানোর জন্য ব্যবহৃত ট্রেড ফেডারেশন টেস্ট ক্লাস এবং কার্যকর করা ডিভাইসের প্যাকেজে পাস এবং টেস্ট রানার ফ্রেমওয়ার্ক যা এই ক্ষেত্রে JUnit তা নির্দিষ্ট করে।

টেস্ট মডিউল কনফিগারেশন সম্পর্কে আরও তথ্যের জন্য এখানে দেখুন।

JUnit4 বৈশিষ্ট্য

android-support-test লাইব্রেরিটিকে টেস্ট রানার হিসেবে ব্যবহার করলে নতুন JUnit4 স্টাইলের টেস্ট ক্লাস গ্রহণ করা সম্ভব হয় এবং নমুনা জেরিট পরিবর্তনে এর বৈশিষ্ট্যগুলির কিছু খুব মৌলিক ব্যবহার রয়েছে।

নমুনা জেরিট পরিবর্তনের সর্বশেষ সোর্স কোডটি এখানে অ্যাক্সেস করা যেতে পারে: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

যদিও পরীক্ষার ধরণগুলি সাধারণত কম্পোনেন্ট টিমের জন্য নির্দিষ্ট, কিছু সাধারণভাবে কার্যকর ব্যবহারের ধরণ রয়েছে।

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

JUnit4 এর একটি উল্লেখযোগ্য পার্থক্য হল যে পরীক্ষাগুলিকে আর একটি সাধারণ বেস টেস্ট ক্লাস থেকে উত্তরাধিকারসূত্রে নেওয়ার প্রয়োজন নেই; পরিবর্তে, আপনি প্লেইন জাভা ক্লাসে পরীক্ষা লিখুন এবং নির্দিষ্ট পরীক্ষার সেটআপ এবং সীমাবদ্ধতাগুলি নির্দেশ করার জন্য অ্যানোটেশন ব্যবহার করুন। এই উদাহরণে, আমরা নির্দেশ দিচ্ছি যে এই ক্লাসটি একটি Android JUnit4 পরীক্ষা হিসাবে চালানো উচিত।

@SmallTest টীকাটি সম্পূর্ণ টেস্ট ক্লাসের জন্য একটি পরীক্ষার আকার নির্দিষ্ট করে: এই টেস্ট ক্লাসে যোগ করা সমস্ত পরীক্ষা পদ্ধতি এই পরীক্ষার আকারের টীকাটি উত্তরাধিকার সূত্রে পায়। প্রি-টেস্ট ক্লাস সেটআপ, পোস্ট-টেস্ট টিয়ার ডাউন এবং পোস্ট-টেস্ট ক্লাস টিয়ার ডাউন: JUnit4-তে setUp এবং tearDown পদ্ধতির অনুরূপ। প্রকৃত পরীক্ষাটি টীকা করার জন্য Test টীকাটি ব্যবহার করা হয়।

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

@Before অ্যানোটেশন JUnit4 এর পদ্ধতিতে প্রি-টেস্ট সেটআপ করার জন্য ব্যবহার করা হয়। যদিও এই উদাহরণে ব্যবহার করা হয়নি, পোস্ট-টেস্ট টিয়ারডাউনের জন্য @After ও আছে। একইভাবে, @BeforeClass এবং @AfterClass অ্যানোটেশনগুলি JUnit4 এর পদ্ধতিতে একটি টেস্ট ক্লাসে সমস্ত পরীক্ষা চালানোর আগে সেটআপ করার জন্য এবং পরে টিয়ারডাউন করার জন্য ব্যবহার করা যেতে পারে। মনে রাখবেন যে ক্লাস-স্কোপ সেটআপ এবং টিয়ারডাউন পদ্ধতিগুলি অবশ্যই স্ট্যাটিক হতে হবে।

পরীক্ষার পদ্ধতিগুলির ক্ষেত্রে, JUnit-এর পূর্ববর্তী সংস্করণের মতো, তাদের আর পদ্ধতির নাম test দিয়ে শুরু করার প্রয়োজন নেই, পরিবর্তে, তাদের প্রতিটি @Test দিয়ে টীকা দিতে হবে। যথারীতি, পরীক্ষার পদ্ধতিগুলি সর্বজনীন হতে হবে, কোনও রিটার্ন মান ঘোষণা করতে হবে না, কোনও প্যারামিটার নিতে হবে না এবং ব্যতিক্রমগুলিও দিতে পারে। 

        Context context = InstrumentationRegistry.getTargetContext();

যেহেতু JUnit4 পরীক্ষাগুলির জন্য আর একটি সাধারণ বেস ক্লাসের প্রয়োজন হয় না, তাই getContext() এর মাধ্যমে Context ইনস্ট্যান্স বা বেস ক্লাস পদ্ধতির মাধ্যমে getTargetContext() প্রাপ্ত করার প্রয়োজন নেই; পরিবর্তে, নতুন টেস্ট রানার InstrumentationRegistry মাধ্যমে সেগুলি পরিচালনা করে যেখানে instrumentation framework দ্বারা তৈরি contextual এবং পরিবেশগত সেটআপ সংরক্ষণ করা হয়। এই ক্লাসের মাধ্যমে, আপনি এটিও কল করতে পারেন:

  • getInstrumentation() : Instrumentation ক্লাসের উদাহরণ
  • getArguments() : কমান্ড লাইন আর্গুমেন্টগুলি -e <key> <value> মাধ্যমে am instrument পাঠানো হয়।

স্থানীয়ভাবে তৈরি করুন এবং পরীক্ষা করুন

সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে, Atest ব্যবহার করুন।

আরও জটিল ক্ষেত্রে যেখানে ভারী কাস্টমাইজেশনের প্রয়োজন হয়, যন্ত্রের নির্দেশাবলী অনুসরণ করুন।