আপনি যদি Android প্ল্যাটফর্ম ডেভেলপমেন্টে নতুন হন, তাহলে আপনি এই সম্পূর্ণ উদাহরণটি দেখতে পারেন। এটিতে একেবারে নতুন GTest বাইনারি (এটি কখনও কখনও "নেটিভ" টেস্টও বলা হয়) যোগ করার প্রসেস দেখানো হয়েছে। এটি আপনাকে সাধারণ ওয়ার্কফ্লো বুঝতে সাহায্য করবে। C++-এর জন্য GTest ফ্রেমওয়ার্ক সম্পর্কে অতিরিক্ত তথ্য পেতে, অতিরিক্ত ডকুমেন্টেশনের জন্য GTest প্রজেক্ট সাইট দেখুন।
এই নির্দেশিকায় Hello World GTest কে উদাহরণ হিসেবে ব্যবহার করা হয়েছে। চালিয়ে যাওয়ার আগে কোডটি পড়ে নিয়ে সেটির ব্যাপারে মোটামুটি ধারণা করে নিলে ভাল হয়।
সোর্স লোকেশন ঠিক করুন
সাধারণত, আপনার টিমের কাছে কোড চেক-ইন করার জায়গা এবং টেস্ট যোগ করার জায়গা সংক্রান্ত একটি প্রতিষ্ঠিত প্যাটার্ন আগে থেকেই থাকবে। বেশিরভাগ টিমের একটি Git রিপোজিটরি থাকে অথবা অন্য টিমের সাথে একটি রিপোজিটরি শেয়ার করে কিন্তু এতে কম্পোনেন্ট সোর্স কোড থাকার জন্য একটি নির্দিষ্ট সাব-ডিরেক্টরি থাকে।
ধরে নেওয়া যাক, আপনার কম্পোনেন্ট সোর্সের রুট লোকেশন <component source
root>-এ আছে, বেশিরভাগ কম্পোনেন্টের মধ্যে src ও tests ফোল্ডার আছে এবং কিছু
অতিরিক্ত ফাইল আছে, যেমন Android.mk (অথবা অতিরিক্ত .bp
ফাইলে ভাগ করা)।
আপনি যেহেতু একদম নতুন টেস্ট যোগ করছেন, তাই আপনাকে সম্ভবত
tests আপনার কম্পোনেন্টের পাশে ডিরেক্টরি src তৈরি করতে হবে এবং কন্টেন্ট দিয়ে এটি পূরণ করতে হবে।
কিছু ক্ষেত্রে, আলাদা আলাদা বাইনারিতে বিভিন্ন ধরনের টেস্টের স্যুটের প্যাকেজ করার প্রয়োজন হওয়ার কারণে, আপনার টিমের কাছে tests-এর অধীনে আরও ডিরেক্টরি স্ট্রাকচার থাকতে পারে।
এই ক্ষেত্রে, আপনাকে tests-এর অধীনে একটি নতুন সাব-ডিরেক্টরি তৈরি করতে হবে।
উদাহরণস্বরূপ, এখানে একটি
tests ফোল্ডার সহ কম্পোনেন্টের জন্য একটি সাধারণ ডিরেক্টরি আউটলাইন দেওয়া হল:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
এবং একাধিক টেস্ট সোর্স ডিরেক্টরি সহ কম্পোনেন্টের জন্য এখানে একটি সাধারণ ডিরেক্টরি আউটলাইন দেওয়া হল:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
স্ট্রাকচার যাই হোক না কেন, আপনি tests ডিরেক্টরি বা
নতুন তৈরি সাব-ডিরেক্টরিকে native-এর মতো ফাইল দিয়ে পূরণ করবেন
স্যাম্পেল Gerrit পরিবর্তন। নিচের বিভাগগুলি প্রতিটি ফাইলের আরও বিবরণ
ব্যাখ্যা করবে।
সোর্স কোড
উদাহরণের জন্য Hello World GTest দেখুন।
সেই উদাহরণের সোর্স কোড এখানে অ্যানোটেট করা আছে:
#include <gtest/gtest.h>
GTest-এর জন্য হেডার ফাইল অন্তর্ভুক্ত করুন। makefile-এ BUILD_NATIVE_TEST ব্যবহার করে ইনক্লুড ফাইল
ডিপেন্ডেন্সি অটোমেটিক সমাধান করা হয়।
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTests TEST ম্যাক্রো ব্যবহার করে লেখা হয়: প্রথম প্যারামিটার হল টেস্ট কেস
নাম এবং দ্বিতীয়টি হল টেস্টের নাম। টেস্ট বাইনারি নামের সাথে, সেগুলি ফলাফল ড্যাশবোর্ডে
নিম্নলিখিত হায়ারার্কি তৈরি করে:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest-এর মাধ্যমে পরীক্ষা লেখা সম্পর্কে আরও জানতে, GTest ডকুমেন্টেশন দেখুন
সহজ কনফিগারেশন ফাইল
প্রতিটি নতুন টেস্ট মডিউলে মডিউল মেটাডেটা, কম্পাইল-টাইম ডিপেন্ডেন্সি ও প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে ডাইরেক্ট করার জন্য একটি কনফিগারেশন ফাইল থাকতে হবে। বেশিরভাগ ক্ষেত্রে, Soong-ভিত্তিক, ব্লুপ্রিন্ট ফাইল বিকল্পটি যথেষ্ট। আরও তথ্যের জন্য সহজ টেস্ট কনফিগারেশন দেখুন।
জটিল কনফিগারেশন ফাইল
পরিবর্তে Trade Federation ব্যবহার করতে, Android-এর টেস্ট হারনেস, Trade Federation-এর জন্য একটি টেস্ট কনফিগারেশন ফাইল লিখুন।
টেস্ট কনফিগারেশন, টেস্ট ক্লাসকে সাপ্লাই করার জন্য বিশেষ ডিভাইস সেট-আপ বিকল্প ও ডিফল্ট আর্গুমেন্ট নির্দিষ্ট করতে পারে।
লোকাল ডিভাইসে তৈরি ও পরীক্ষা করুন
সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে, Atest ব্যবহার করুন।
আরও জটিল কেসের জন্য, যেখানে আরও বেশি কাস্টমাইজেশনের প্রয়োজন, সেখানে ইনস্ট্রুমেন্টেশন সংক্রান্ত নির্দেশাবলী অনুসরণ করুন।