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

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

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

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

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

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

একটি উৎস অবস্থান সিদ্ধান্ত

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

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

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

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

আরও এগিয়ে যাওয়ার আগে, প্রথমে অ্যাপ ম্যানিফেস্ট ওভারভিউ দেখে নেওয়ার জন্য এটি অত্যন্ত সুপারিশ করা হয়।

এটি একটি ম্যানিফেস্ট ফাইলের মৌলিক উপাদান এবং তাদের কার্যকারিতাগুলির একটি ওভারভিউ দেয়।

নমুনা গেরিট পরিবর্তনের জন্য ম্যানিফেস্ট ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: https://android.googlesource.com/platform/frameworks/base/+/main/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 প্রক্রিয়াটি পুনরায় চালু করে এবং পরীক্ষা সম্পাদনের জন্য প্রক্রিয়ার মধ্যে ইনস্ট্রুমেন্টেশন কোড ইনজেক্ট করে। এর মানে হল যে পরীক্ষার কোডটি পরীক্ষার অধীনে অ্যাপ্লিকেশনে চলমান সমস্ত শ্রেণির দৃষ্টান্তগুলিতে অ্যাক্সেস পাবে এবং পরীক্ষার হুকগুলি উন্মোচিত হওয়ার উপর নির্ভর করে রাজ্যকে ম্যানিপুলেট করতে সক্ষম হতে পারে।

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

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

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

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

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

নমুনা গেরিট পরিবর্তনের জন্য কনফিগার ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: 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() বা getTargetContext() মাধ্যমে Context দৃষ্টান্তগুলি পাওয়ার আর প্রয়োজন নেই; পরিবর্তে, নতুন টেস্ট রানার InstrumentationRegistry মাধ্যমে তাদের পরিচালনা করে যেখানে ইন্সট্রুমেন্টেশন ফ্রেমওয়ার্ক দ্বারা তৈরি প্রাসঙ্গিক এবং পরিবেশগত সেটআপ সংরক্ষণ করা হয়। এই ক্লাসের মাধ্যমে, আপনি কল করতে পারেন:

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

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

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

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

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

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

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

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

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

একটি উৎস অবস্থান সিদ্ধান্ত

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

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

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

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

আরও এগিয়ে যাওয়ার আগে, প্রথমে অ্যাপ ম্যানিফেস্ট ওভারভিউ দেখে নেওয়ার জন্য এটি অত্যন্ত সুপারিশ করা হয়।

এটি একটি ম্যানিফেস্ট ফাইলের মৌলিক উপাদান এবং তাদের কার্যকারিতাগুলির একটি ওভারভিউ দেয়।

নমুনা গেরিট পরিবর্তনের জন্য ম্যানিফেস্ট ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: https://android.googlesource.com/platform/frameworks/base/+/main/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 প্রক্রিয়াটি পুনরায় চালু করে এবং পরীক্ষা সম্পাদনের জন্য প্রক্রিয়ার মধ্যে ইনস্ট্রুমেন্টেশন কোড ইনজেক্ট করে। এর মানে হল যে পরীক্ষার কোডটি পরীক্ষার অধীনে অ্যাপ্লিকেশনে চলমান সমস্ত শ্রেণির দৃষ্টান্তগুলিতে অ্যাক্সেস পাবে এবং পরীক্ষার হুকগুলি উন্মোচিত হওয়ার উপর নির্ভর করে রাজ্যকে ম্যানিপুলেট করতে সক্ষম হতে পারে।

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

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

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

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

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

নমুনা গেরিট পরিবর্তনের জন্য কনফিগার ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: 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() বা getTargetContext() মাধ্যমে Context দৃষ্টান্তগুলি পাওয়ার আর প্রয়োজন নেই; পরিবর্তে, নতুন টেস্ট রানার InstrumentationRegistry মাধ্যমে তাদের পরিচালনা করে যেখানে ইন্সট্রুমেন্টেশন ফ্রেমওয়ার্ক দ্বারা তৈরি প্রাসঙ্গিক এবং পরিবেশগত সেটআপ সংরক্ষণ করা হয়। এই ক্লাসের মাধ্যমে, আপনি কল করতে পারেন:

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

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

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

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

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

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

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

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

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

একটি উৎস অবস্থান সিদ্ধান্ত

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

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

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

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

আরও এগিয়ে যাওয়ার আগে, প্রথমে অ্যাপ ম্যানিফেস্ট ওভারভিউ দেখে নেওয়ার জন্য এটি অত্যন্ত সুপারিশ করা হয়।

এটি একটি ম্যানিফেস্ট ফাইলের মৌলিক উপাদান এবং তাদের কার্যকারিতাগুলির একটি ওভারভিউ দেয়।

নমুনা গেরিট পরিবর্তনের জন্য ম্যানিফেস্ট ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: https://android.googlesource.com/platform/frameworks/base/+/main/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 প্রক্রিয়াটি পুনরায় চালু করে এবং পরীক্ষা সম্পাদনের জন্য প্রক্রিয়ার মধ্যে ইনস্ট্রুমেন্টেশন কোড ইনজেক্ট করে। এর মানে হল যে পরীক্ষার কোডটি পরীক্ষার অধীনে অ্যাপ্লিকেশনে চলমান সমস্ত শ্রেণির দৃষ্টান্তগুলিতে অ্যাক্সেস পাবে এবং পরীক্ষার হুকগুলি উন্মোচিত হওয়ার উপর নির্ভর করে রাজ্যকে ম্যানিপুলেট করতে সক্ষম হতে পারে।

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

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

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

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

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

নমুনা গেরিট পরিবর্তনের জন্য কনফিগার ফাইলের সর্বশেষ সংস্করণটি এখানে অ্যাক্সেস করা যেতে পারে: 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() বা getTargetContext() মাধ্যমে Context দৃষ্টান্তগুলি পাওয়ার আর প্রয়োজন নেই; পরিবর্তে, নতুন টেস্ট রানার InstrumentationRegistry মাধ্যমে তাদের পরিচালনা করে যেখানে ইন্সট্রুমেন্টেশন ফ্রেমওয়ার্ক দ্বারা তৈরি প্রাসঙ্গিক এবং পরিবেশগত সেটআপ সংরক্ষণ করা হয়। এই ক্লাসের মাধ্যমে, আপনি কল করতে পারেন:

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

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

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

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