این صفحه به شما می گوید که چگونه یک تست سمت میزبان بنویسید که به دستگاهی نیاز ندارد، مانند آزمایشی که روی نمونه GCE لینوکس اجرا می شود. (برای جزئیات در مورد نوشتن یک آزمون میزبان محور که به دستگاه نیاز دارد، به نوشتن تست میزبان محور در فدراسیون تجارت مراجعه کنید.)
انواع تست سمت میزبان
شما می توانید انواع مختلفی از تست های سمت میزبان را از طریق Trade Federation (TF) اجرا کنید.
تست های بومی (gtest).
برای آزمایش یک پلتفرم ، تست های بومی (gtests) ایجاد کنید. اگر آزمایش به دستگاهی نیاز ندارد، آن را روی یک میزبان اجرا کنید. به این ترتیب تست خیلی سریعتر اجرا می شود. برای پیکربندی چنین آزمایشهایی برای اجرا در میزبان آزمایشی، از TF runner HostGTest استفاده کنید.
این یک نمونه پیکربندی تست TradeFed است:
<configuration description="Runs hello_world_test."> <option name="null-device" value="true" /> <test class="com.android.tradefed.testtype.HostGTest" > <option name="module-name" value="hello_world_test" /> </test> </configuration>
پیکربندی تست یک آزمایش gtest ( hello_world_test ) را روی یک میزبان اجرا میکند. پیکربندی آزمایشی نمونه را می توان به طور خودکار ایجاد کرد. مگر اینکه تست شما نیاز به راه اندازی یا پاکسازی خاصی داشته باشد، می توانید برای ایجاد تنظیمات تست TF مناسب به تولید تنظیمات خودکار تست تکیه کنید.
برای پیکربندی gtest سمت میزبان و فعال کردن تولید خودکار test-config، host_supported
را در Android.bp
روی true
تنظیم کنید، مانند hello_world_test .
برای اطلاعات بیشتر در مورد نوشتن یک آزمون بومی، به افزودن نمونه آزمون بومی جدید مراجعه کنید.
تست میزبان JAR
تستهای میزبان JAR (جاوا) ، مانند JUnit، تستهایی هستند که نیازی به اجرا بر روی دستگاه ندارند و پوشش کد پروژه جاوا شما را فراهم میکنند. با استفاده از runner HostTest میتوان چنین آزمایشهایی را برای اجرا در میزبان آزمایشی پیکربندی کرد.
نمونه پیکربندی تست TradeFed
<configuration description="Executes HelloWorldHostTest"> <test class="com.android.tradefed.testtype.HostTest" > <option name="jar" value="HelloWorldHostTest.jar" /> </test> </configuration>
پیکربندی آزمایشی تست JUnit سمت میزبان HelloWorldHostTest را اجرا می کند. توجه داشته باشید که پیکربندی تست بالا را می توان به صورت خودکار ایجاد کرد. مگر اینکه تست شما نیاز به راه اندازی یا پاکسازی خاصی داشته باشد، برای ایجاد پیکربندی تست TradeFed مناسب، به تولید تنظیمات خودکار تست تکیه کنید.
برای جزئیات بیشتر در مورد نحوه نوشتن تست میزبان JAR، به صفحه تست هاست JAR (جاوا) مراجعه کنید.
تست های میزبان جاوا جدا شده
تست های جاوا بدون دستگاه را می توان در یک محیط ایزوله با هزینه عملکرد کمی اجرا کرد. با این حال، برخی از ملاحظات عمده وجود دارد که قبل از انتخاب استفاده از این محیط باید مورد توجه قرار گیرد.
- این رانر پیشفرض برای تستهای روبولکتریک و واحد JUnit استفاده میشود
- Tradefed فقط از تست های JUnit در محیط ایزوله پشتیبانی می کند.
- فقط وابستگی هایی که به صورت ایستا مرتبط هستند پشتیبانی می شوند. هیچ وابستگی اعلام شده با
lib
در مسیر کلاس گنجانده نشده است. - دونده ایزوله فقط شیم رانر و شیشه تست شما را در مسیر کلاس قرار می دهد.
- مقداری سربار ثابت در هر اجرای آزمایشی با این رانر وجود دارد.
نمونه پیکربندی تست Tradefed (ایزوله)
<configuration description="Executes HelloWorldHostTest"> <test class="com.android.tradefed.testtype.IsolatedHostTest" > <option name="jar" value="HelloWorldHostTest.jar" /> </test> </configuration>
نمونه پیکربندی Soong برای تولید خودکار
به جای ایجاد دستی پیکربندی آزمایشی مانند بالا ، Soong میتواند پیکربندی را با استفاده از اعلانی مانند این مثال ایجاد کند.
java_test_host { name: "HelloWorldHostTest", test_options: { unit_test: true, }, test_suites: ["general-tests"], srcs: ["test/**/*.java"], static_libs: [ "junit", ], }
تست های روبولکتریک
تستهای روبولکتریک از همان دونده تست میزبان مجزا با چند گزینه خاص استفاده میکنند.
- گزینه
robolectric-resources
چند گزینه خط فرمان خاص Robolectric را قادر میسازد تا به زیر فرآیند منتقل شوند و همچنین ساختار درختیandroid-all
را به مسیر کلاس فرعی اضافه میکند. در حالی که دو مورد دیگر بهترین روشها هستند، این گزینه برای اجرای تستهای Robolectric با هر موفقیتی الزامی است. - گزینه
java-folder
اجازه می دهد تا زمان اجرا جاوا مورد استفاده توسط زیرفرآیند را تغییر دهید. این به دلیل ترجیح Robolectric نسخه های خاص جاوا که ممکن است با JVM ترجیحی سیستم میزبان هماهنگ نباشد، ضروری است. - گزینه
exclude-paths
به اجراکننده زیرفرآیند اجازه میدهد تا از بارگذاری ماژولهای خاص به هیچ وجه اجتناب کند، که زمانی مفید است که یک JAR با کلاسهای اضافی همراه باشد که میتواند باعث خطای بار شود.java.
برای جلوگیری از پرتاب استثناهایSecurityException
یک استثنا معمول است.
نمونه پیکربندی Robolectric
<configuration description="Executes a Sample Robolectric Test"> <option name="java-folder" value="prebuilts/jdk/jdk9/linux-x86/" /> <option name="exclude-paths" value="java" /> <option name="use-robolectric-resources" value="true" /> <test class="com.android.tradefed.testtype.IsolatedHostTest"> <option name="jar" value="RobolectricExampleTest.jar" /> </test> </configuration>
نمونه پیکربندی Soong برای تولید خودکار روبولکتریک
به جای ایجاد دستی پیکربندی آزمایشی مانند بالا ، Soong میتواند پیکربندی را با استفاده از اعلانی مانند این مثال ایجاد کند.
android_robolectric_test { name: "HelloWorldRoboTest", srcs: [ "src/**/*.java", ], // Include the testing libraries static_libs: [ "mockito-robolectric-prebuilt", "platform-test-annotations", "testng", "truth-prebuilt", ], instrumentation_for: "HelloWorldApp", }
تست پایتون
اگر منطق تست در پایتون نوشته شده است، از نوع ساخت python_test_host
برای ایجاد یک فایل par که می تواند توسط TF PythonBinaryHostTest
اجرا شود، استفاده کنید.
نمونه پیکربندی تست TradeFed
<configuration description="Config to run atest unittests"> <test class="com.android.tradefed.testtype.python.PythonBinaryHostTest" > <option name="par-file-name" value="atest_unittests" /> <option name="test-timeout" value="2m" /> </test> </configuration>
تنظیمات مجموعه آزمایشی
برای اینکه تست سمت میزبان توسط TF برای یک ساخت معین قابل دسترسی باشد، ماژول تست `test_suites`
را روی `general-tests`
تنظیم کنید:
test_suites: ["general-tests"],
با این تنظیم، تست به general-tests.zip
در هدف test_suites
بسته بندی می شود.