আপনি যদি অ্যান্ড্রয়েড প্ল্যাটফর্ম ডেভেলপমেন্টে নতুন হয়ে থাকেন, তাহলে আপনি একটি নতুন 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
| \-- ...
\-- ...
গঠন নির্বিশেষে, আপনি নমুনা গেরিট পরিবর্তনে native ডিরেক্টরিতে যা আছে তার অনুরূপ ফাইল সহ tests ডিরেক্টরি বা নতুন তৈরি সাব ডিরেক্টরিকে পপুলেট করে ফেলবেন। নীচের বিভাগগুলি প্রতিটি ফাইলের আরও বিশদ ব্যাখ্যা করবে।
সোর্স কোড
একটি উদাহরণের জন্য Hello World GTest পড়ুন।
সেই উদাহরণের জন্য সোর্স কোড এখানে টীকা করা হয়েছে:
#include <gtest/gtest.h>
হেডার ফাইল GTest জন্য অন্তর্ভুক্ত. অন্তর্ভুক্ত ফাইল নির্ভরতা মেকফাইলে 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 ডকুমেন্টেশন পড়ুন
সহজ কনফিগারেশন ফাইল
প্রতিটি নতুন টেস্ট মডিউলের অবশ্যই একটি কনফিগারেশন ফাইল থাকতে হবে যাতে মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী সহ বিল্ড সিস্টেমকে নির্দেশিত করা যায়। বেশিরভাগ ক্ষেত্রে, সুং-ভিত্তিক, ব্লুপ্রিন্ট ফাইল বিকল্পটি যথেষ্ট। বিস্তারিত জানার জন্য সাধারণ পরীক্ষা কনফিগারেশন দেখুন।
জটিল কনফিগারেশন ফাইল
পরিবর্তে ট্রেড ফেডারেশন ব্যবহার করতে, অ্যান্ড্রয়েডের টেস্ট হার্নেস, ট্রেড ফেডারেশনের জন্য একটি পরীক্ষা কনফিগারেশন ফাইল লিখুন।
পরীক্ষার কনফিগারেশন পরীক্ষা ক্লাস সরবরাহ করার জন্য বিশেষ ডিভাইস সেটআপ বিকল্প এবং ডিফল্ট আর্গুমেন্ট নির্দিষ্ট করতে পারে।
স্থানীয়ভাবে তৈরি করুন এবং পরীক্ষা করুন
সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে, Atest ব্যবহার করুন।
আরও জটিল ক্ষেত্রে ভারী কাস্টমাইজেশন প্রয়োজন, উপকরণ নির্দেশাবলী অনুসরণ করুন।