আপনি যদি অ্যান্ড্রয়েড প্ল্যাটফর্ম ডেভেলপমেন্টে নতুন হন, তবে একেবারে শুরু থেকে একটি সম্পূর্ণ নতুন GTest বাইনারি (যাকে কখনও কখনও "নেটিভ" টেস্টও বলা হয়) যোগ করার এই পূর্ণাঙ্গ উদাহরণটি আপনার জন্য সহায়ক হতে পারে, যা এর সাথে জড়িত সাধারণ কার্যপ্রবাহটি প্রদর্শন করে। C++ এর জন্য GTest ফ্রেমওয়ার্ক সম্পর্কে অতিরিক্ত তথ্যের জন্য, আরও ডকুমেন্টেশনের জন্য GTest প্রজেক্ট সাইটটি দেখুন।
এই নির্দেশিকায় উদাহরণ হিসেবে Hello World GTest ব্যবহার করা হয়েছে। সামনে এগোনোর আগে, কোডটি পড়ে এটি সম্পর্কে একটি মোটামুটি ধারণা নেওয়ার জন্য আমরা আপনাকে পরামর্শ দিচ্ছি।
উৎস স্থান নির্ধারণ করুন
সাধারণত আপনার টিমের কোড চেক-ইন করার এবং টেস্ট যোগ করার জন্য একটি প্রতিষ্ঠিত পদ্ধতি আগে থেকেই থাকে। বেশিরভাগ টিমের নিজস্ব একটি গিট রিপোজিটরি থাকে, অথবা তারা অন্য টিমের সাথে একটি শেয়ার করে, কিন্তু কম্পোনেন্টের সোর্স কোড রাখার জন্য একটি ডেডিকেটেড সাব-ডিরেক্টরি থাকে।
ধরে নিচ্ছি আপনার কম্পোনেন্ট সোর্সের মূল অবস্থান হলো <component source root> । বেশিরভাগ কম্পোনেন্টের অধীনে src এবং tests ফোল্ডার থাকে এবং Android.mk এর মতো কিছু অতিরিক্ত ফাইলও থাকে (অথবা সেগুলো আরও কিছু .bp ফাইলে বিভক্ত থাকতে পারে)।
যেহেতু আপনি একটি একদম নতুন টেস্ট যোগ করছেন, তাই সম্ভবত আপনাকে আপনার কম্পোনেন্ট src পাশে tests ডিরেক্টরিটি তৈরি করতে হবে এবং সেটিকে কন্টেন্ট দিয়ে পূর্ণ করতে হবে।
কিছু ক্ষেত্রে, বিভিন্ন টেস্ট স্যুটকে পৃথক বাইনারিতে প্যাকেজ করার প্রয়োজনের কারণে আপনার টিমের 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 ডিরেক্টরিতে থাকা ফাইলগুলোর মতোই। নিচের সেকশনগুলোতে প্রতিটি ফাইল সম্পর্কে আরও বিস্তারিতভাবে ব্যাখ্যা করা হবে।
উৎস কোড
একটি উদাহরণের জন্য হ্যালো ওয়ার্ল্ড জিটেস্টটি দেখুন।
সেই উদাহরণটির সোর্স কোড এখানে টীকাসহ দেওয়া হলো:
#include <gtest/gtest.h>
GTest-এর জন্য হেডার ফাইল অন্তর্ভুক্ত করা হয়েছে। মেকফাইলে BUILD_NATIVE_TEST ব্যবহার করার মাধ্যমে ইনক্লুড ফাইলের নির্ভরতা স্বয়ংক্রিয়ভাবে সমাধান করা হয়।
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest-গুলো TEST ম্যাক্রো ব্যবহার করে লেখা হয়: এর প্রথম প্যারামিটারটি হলো টেস্ট কেসের নাম এবং দ্বিতীয়টি হলো টেস্টের নাম। টেস্ট বাইনারি নামের সাথে মিলে, এগুলি রেজাল্ট ড্যাশবোর্ডে নিম্নলিখিত ক্রমবিন্যাস তৈরি করে:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest দিয়ে টেস্ট লেখার বিষয়ে আরও তথ্যের জন্য, GTest ডকুমেন্টেশন দেখুন।
সাধারণ কনফিগারেশন ফাইল
প্রতিটি নতুন টেস্ট মডিউলের একটি কনফিগারেশন ফাইল থাকা আবশ্যক, যা মডিউল মেটাডেটা, কম্পাইল-টাইম ডিপেন্ডেন্সি এবং প্যাকেজিং নির্দেশাবলী দিয়ে বিল্ড সিস্টেমকে পরিচালনা করে। বেশিরভাগ ক্ষেত্রে, সুং-ভিত্তিক ব্লুপ্রিন্ট ফাইল বিকল্পটিই যথেষ্ট। বিস্তারিত জানতে সিম্পল টেস্ট কনফিগারেশন দেখুন।
জটিল কনফিগারেশন ফাইল
এর পরিবর্তে ট্রেড ফেডারেশন ব্যবহার করতে, অ্যান্ড্রয়েডের টেস্ট হারনেস, ট্রেড ফেডারেশন- এর জন্য একটি টেস্ট কনফিগারেশন ফাইল লিখুন।
টেস্ট কনফিগারেশনে টেস্ট ক্লাসে সরবরাহ করার জন্য বিশেষ ডিভাইস সেটআপ অপশন এবং ডিফল্ট আর্গুমেন্ট নির্দিষ্ট করা যেতে পারে।
স্থানীয়ভাবে তৈরি ও পরীক্ষা করুন
সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে Atest ব্যবহার করুন।
আরও জটিল ক্ষেত্রগুলির জন্য, যেখানে ব্যাপকতর কাস্টমাইজেশনের প্রয়োজন হয়, সেখানে ইন্সট্রুমেন্টেশন নির্দেশাবলী অনুসরণ করুন।