স্ব-ইনস্ট্রুমেন্টিং টেস্টের উদাহরণ

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

এর মানে হল যে একটি ইন্সট্রুমেন্টেশন পরীক্ষা নিজেকে অ্যান্ড্রয়েড ফ্রেমওয়ার্ক, ওরফে সিস্টেম সার্ভারে, কার্যকর করার জন্য ইনজেক্ট করতে পারে না। অ্যান্ড্রয়েড ফ্রেমওয়ার্ক পরীক্ষা করার জন্য, টেস্ট কোড শুধুমাত্র পাবলিক এপিআই সারফেস, বা প্ল্যাটফর্ম সোর্স ট্রিতে উপলব্ধ অ্যান্ড্রয়েড ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ AIDL এর মাধ্যমে উন্মুক্ত করা যেতে পারে। এই শ্রেণীর পরীক্ষার জন্য, কোনো নির্দিষ্ট প্যাকেজকে লক্ষ্য করা অর্থপূর্ণ নয়। তাই, AndroidManifest.xml এর নিজস্ব <manifest> ট্যাগে সংজ্ঞায়িত এই ধরনের যন্ত্রগুলির নিজস্ব পরীক্ষা অ্যাপ্লিকেশন প্যাকেজ লক্ষ্য করার জন্য ঘোষণা করা প্রথাগত।

প্রয়োজনীয়তার উপর নির্ভর করে, এই বিভাগে পরীক্ষামূলক অ্যাপ্লিকেশন প্যাকেজগুলিও হতে পারে:

• পরীক্ষার জন্য প্রয়োজনীয় বান্ডিল কার্যক্রম।
• সিস্টেমের সাথে ইউজার আইডি শেয়ার করুন।
• প্ল্যাটফর্ম কী দিয়ে স্বাক্ষর করুন।
• পাবলিক SDK এর পরিবর্তে ফ্রেমওয়ার্ক সোর্সের বিরুদ্ধে কম্পাইল করুন।

ইন্সট্রুমেন্টেশন পরীক্ষার এই বিভাগকে কখনও কখনও স্ব-ইন্সট্রুমেন্টেশন হিসাবে উল্লেখ করা হয়। প্ল্যাটফর্মের উৎসে স্ব-ইনস্ট্রুমেন্টেশন পরীক্ষার কিছু উদাহরণ এখানে দেওয়া হল:

• ফ্রেমওয়ার্ক/বেস/কোর/পরীক্ষা/
• ফ্রেমওয়ার্ক/বেস/পরিষেবা/পরীক্ষা/পরিষেবা

এখানে কভার করা উদাহরণটি তার নিজস্ব পরীক্ষা অ্যাপ্লিকেশন প্যাকেজে লক্ষ্য প্যাকেজ সেট সহ একটি নতুন ইন্সট্রুমেন্টেশন পরীক্ষা লিখছে। এই গাইড একটি উদাহরণ হিসাবে পরিবেশন করার জন্য নিম্নলিখিত পরীক্ষা ব্যবহার করে:

• হ্যালো ওয়ার্ল্ড ইন্সট্রুমেন্টেশন টেস্ট

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

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

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

আপনার কম্পোনেন্ট সোর্সের রুট অবস্থান <component source root> -এ আছে বলে ধরে নিলাম, বেশিরভাগ কম্পোনেন্টে এর অধীনে src এবং tests ফোল্ডার রয়েছে এবং কিছু অতিরিক্ত ফাইল যেমন Android.mk (বা অতিরিক্ত .mk ফাইলে বিভক্ত), ম্যানিফেস্ট ফাইল AndroidManifest.xml , এবং পরীক্ষা কনফিগারেশন ফাইল 'AndroidTest.xml'।

যেহেতু আপনি একটি একেবারে নতুন পরীক্ষা যোগ করছেন, তাই আপনাকে সম্ভবত আপনার কম্পোনেন্ট src এর পাশে tests ডিরেক্টরি তৈরি করতে হবে এবং এটিকে বিষয়বস্তু দিয়ে তৈরি করতে হবে।

কিছু ক্ষেত্রে, পৃথক apks-এ পরীক্ষার বিভিন্ন স্যুট প্যাকেজ করার প্রয়োজনের কারণে আপনার টিমের আরও নির্দেশিকা কাঠামো tests অধীনে থাকতে পারে। এবং এই ক্ষেত্রে, আপনাকে tests অধীনে একটি নতুন সাব ডিরেক্টরি তৈরি করতে হবে।

গঠন নির্বিশেষে, আপনি নমুনা গেরিট পরিবর্তনের instrumentation ডিরেক্টরিতে যা আছে তার অনুরূপ ফাইল সহ tests ডিরেক্টরি বা নতুন তৈরি সাব ডিরেক্টরিকে পপুলেট করে ফেলবেন। নীচের বিভাগগুলি প্রতিটি ফাইলের আরও বিশদ ব্যাখ্যা করবে।

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

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

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

এটি একটি ম্যানিফেস্ট ফাইলের মৌলিক উপাদান এবং তাদের কার্যকারিতাগুলির একটি ওভারভিউ দেয়। platform_testing/tests/example/instrumentation/AndroidManifest.xml- এ উদাহরণ দেখুন।

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <application/>

    <instrumentation android:name="androidx.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

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

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

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

android:sharedUserId="android.uid.system"

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

• কিছু অনুমতি বা API স্বাক্ষর সুরক্ষিত, যার জন্য একই স্বাক্ষর শংসাপত্র প্রয়োজন
• কিছু অনুমতি বা API-এর জন্য কলারের system ব্যবহারকারী পরিচয় প্রয়োজন, যার জন্য কলিং প্যাকেজ প্রয়োজন system সাথে ব্যবহারকারী আইডি শেয়ার করতে, যদি এটি মূল প্ল্যাটফর্ম থেকে একটি পৃথক প্যাকেজ হয়

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

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

android:targetPackage="android.test.example.helloworld"

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

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

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

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

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

পরীক্ষার কনফিগারেশন পরীক্ষা ক্লাস সরবরাহ করার জন্য বিশেষ ডিভাইস সেটআপ বিকল্প এবং ডিফল্ট আর্গুমেন্ট নির্দিষ্ট করতে পারে। উদাহরণটি /platform_testing/tests/example/instrumentation/AndroidTest.xml- এ দেখুন।

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

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <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="HelloWorldTests.apk"/>
</target_preparer>

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

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

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

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

JUnit4 বৈশিষ্ট্য

টেস্ট রানার হিসাবে android-support-test লাইব্রেরি ব্যবহার করা নতুন JUnit4 শৈলী পরীক্ষা ক্লাস গ্রহণ করতে সক্ষম করে, এবং নমুনা গেরিট পরিবর্তনে এর বৈশিষ্ট্যগুলির কিছু খুব প্রাথমিক ব্যবহার রয়েছে। উদাহরণটি দেখুন /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java এ।

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

@RunWith(JUnit4.class)
public class HelloWorldTest {

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

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

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

গুরুত্বপূর্ণ : পরীক্ষার পদ্ধতিগুলি নিজেই @Test টীকা দিয়ে টীকা করা হয়; এবং মনে রাখবেন যে APCT এর মাধ্যমে পরীক্ষা চালানোর জন্য, সেগুলিকে অবশ্যই পরীক্ষার আকার সহ টীকা দিতে হবে: উদাহরণ টীকা পদ্ধতি testHelloWorld @SmallTest । টীকা মেথড স্কোপ বা ক্লাস স্কোপে প্রয়োগ করা যেতে পারে।

instrumentation অ্যাক্সেস করা হচ্ছে

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

যেহেতু JUnit4 পরীক্ষার জন্য আর সাধারণ বেস ক্লাসের প্রয়োজন হয় না, তাই InstrumentationTestCase#getInstrumentation() এর মাধ্যমে Instrumentation ইনস্ট্যান্স পাওয়ার আর প্রয়োজন নেই, পরিবর্তে, নতুন পরীক্ষা রানার এটিকে InstrumentationRegistry এর মাধ্যমে পরিচালনা করে যেখানে InstrumentationRegistry ফ্রেমওয়ার্ক দ্বারা তৈরি প্রাসঙ্গিক এবং পরিবেশগত সেটআপ সংরক্ষণ করা হয়।

InstrumentationRegistry ক্লাসের উদাহরণ অ্যাক্সেস করতে, Instrumentation ক্লাসে স্ট্যাটিক মেথড getInstrumentation() কল করুন:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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