یک دونده تست Tradefed بنویسید

در این صفحه نحوه نوشتن یک تست جدید در Tradefed توضیح داده شده است.

پس زمینه

اگر در مورد جایگاه دونده های آزمایشی در معماری Tradefed کنجکاو هستید، به ساختار یک آزمون دونده مراجعه کنید.

این پیش نیاز برای نوشتن یک تست جدید نیست. دونده های آزمایشی را می توان به صورت مجزا نوشت.

حداقل: رابط را پیاده سازی کنید

حداقل حداقل برای واجد شرایط بودن به عنوان یک دونده آزمایشی Tradefed، پیاده سازی رابط IRemoteTest و به طور خاص تر روش run(TestInformation testInfo, ITestInvocationListener listener) است.

این روش همان روشی است که توسط هارنس هنگام استفاده از اجرای آزمایشی، شبیه به Java Runnable، فراخوانی می شود.

هر بخش از آن متد بخشی از اجرای اجرای آزمایشی در نظر گرفته می شود.

نتایج را از دونده آزمون گزارش دهید

روش run در رابط پایه به یک شی شنونده از نوع ITestInvocationListener دسترسی می دهد. این شی کلید گزارش نتایج ساختاریافته از دونده آزمایشی به مهار است.

با گزارش نتایج ساختاریافته، یک دونده آزمایشی دارای ویژگی های زیر است:

• فهرست مناسبی از تمام آزمون‌هایی که انجام شده، مدت زمان طول کشیده و اینکه آیا به صورت جداگانه قبول شده‌اند، شکست خورده‌اند یا برخی از وضعیت‌های دیگر را گزارش کنید.
• در صورت وجود، معیارهای مرتبط با آزمایش‌ها را گزارش دهید، برای مثال معیارهای زمان نصب.
• در اکثر ابزارهای زیرساختی، به عنوان مثال نمایش نتایج و معیارها و غیره، مناسب است.
• معمولاً اشکال زدایی آسان تر است زیرا ردی از اجرا وجود دارد.

گفته شد، گزارش نتایج ساختاریافته اختیاری است. یک دونده آزمایشی ممکن است به سادگی بخواهد وضعیت کل اجرا را به عنوان گذرانده یا ناموفق ارزیابی کند، بدون اینکه جزئیاتی از اجرای واقعی وجود داشته باشد.

توجه: اجرای رانر که دنباله ای از رویدادها را دنبال می کند دشوارتر است، اما با توجه به مزایای ذکر شده در بالا توصیه می کنیم این کار را انجام دهید.

رویدادهای زیر را می توان از شنونده فراخوانی کرد تا به مهار پیشرفت فعلی اعدام ها اطلاع دهد:

• testRunStarted: شروع گروهی از موارد آزمایشی را که با هم مرتبط هستند اطلاع دهید.
  • testStarted: شروع یک مورد آزمایشی را مطلع کنید.
  • testFailed/testIgnored: تغییر وضعیت مورد آزمایشی در حال انجام را اطلاع دهید. یک مورد آزمایشی بدون هیچ تغییری در وضعیت قبول شده تلقی می شود.
  • testEnded: به پایان پرونده آزمایشی اطلاع دهید.
• testRunFailed: به اطلاع می رساند که وضعیت کلی اجرای گروه تست موارد با شکست مواجه شده است. اجرای آزمایشی بسته به آنچه اجرا انتظار داشت ، مستقل از نتایج آزمایشی ممکن است یک موفقیت یا شکست باشد. به عنوان مثال، یک باینری که چندین مورد آزمایشی را اجرا می‌کند، می‌تواند همه موارد تست قبولی را گزارش کند اما با یک کد خروج خطا (به هر دلیلی: فایل‌های لو رفته و غیره).
• testRunEnded: به پایان گروه موارد تست اطلاع دهید.

حفظ و اطمینان از ترتیب مناسب تماس‌ها بر عهده پیاده‌کننده اجرای آزمایشی است، برای مثال اطمینان از فراخوانی testRunEnded در صورت استثنا با استفاده از یک بند finally .

فراخوانی موارد تست ( testStarted ، testEnded و غیره) اختیاری هستند. اجرای آزمایشی ممکن است بدون هیچ مورد آزمایشی رخ دهد.

ممکن است متوجه شوید که این ساختار رویدادها از ساختار معمولی JUnit الهام گرفته شده است. این به منظور نزدیک نگه داشتن چیزها به چیزی اساسی است که توسعه دهندگان معمولاً درباره آن اطلاعات دارند.

گزارش گزارش‌ها از دونده آزمون

اگر کلاس تست Tradefed یا runner خود را می نویسید، IRemoteTest را پیاده سازی کرده و از طریق متد run() ITestInvocationListener دریافت می کنید. از این شنونده می توان برای لاگ فایل ها به صورت زیر استفاده کرد:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

با دستگاه تست کنید

حداقل رابط بالا اجازه می دهد تا تست های بسیار ساده ای را اجرا کنید که ایزوله هستند و به منابع خاصی نیاز ندارند، به عنوان مثال تست های واحد جاوا.

نویسندگان تست که می خواهند به مرحله بعدی تست دستگاه بروند به رابط های زیر نیاز دارند:

• IDeviceTest اجازه می دهد تا شی ITestDevice را دریافت کنید که نشان دهنده دستگاه تحت آزمایش است و API را برای تعامل با آن فراهم می کند.
• IBuildReceiver به تست اجازه می دهد تا شی IBuildInfo در مرحله ارائه دهنده ساخت ایجاد کند که حاوی تمام اطلاعات و مصنوعات مربوط به تنظیم تست است.

دونده های آزمایشی معمولاً به این رابط ها علاقه مند هستند تا مصنوعات مربوط به اجرا را دریافت کنند، به عنوان مثال فایل های اضافی و دستگاهی را تحت آزمایش قرار دهند که در طول اجرا مورد هدف قرار می گیرد.

تست با چندین دستگاه

Tradefed از اجرای همزمان تست ها بر روی چندین دستگاه پشتیبانی می کند. این برای آزمایش اجزایی که نیاز به تعامل خارجی دارند، مانند جفت شدن تلفن و ساعت، مفید است.

برای نوشتن یک آزمایشی که بتواند از چندین دستگاه استفاده کند، باید IMultiDeviceTest را پیاده سازی کنید، که به شما امکان می دهد نقشه ای از ITestDevice را در IBuildInfo دریافت کنید که حاوی لیست کامل نمایش های دستگاه و اطلاعات ساخت مرتبط با آنها است.

تنظیم کننده از رابط همیشه قبل از متد run فراخوانی می شود، بنابراین می توان فرض کرد که ساختار هنگام فراخوانی run در دسترس خواهد بود.

آزمایش ها از تنظیمات خود آگاه هستند

توجه: این یک مورد استفاده معمولی نیست. برای کامل بودن مستند شده است، اما معمولاً به آن نیاز نخواهید داشت.

برخی از پیاده‌سازی‌های اجراکننده آزمایشی ممکن است به اطلاعاتی در مورد تنظیمات کلی نیاز داشته باشند تا به درستی کار کنند، به عنوان مثال برخی از ابرداده‌ها در مورد فراخوانی، یا اینکه کدام target_preparer قبلا اجرا شده است و غیره.

برای دستیابی به این هدف، یک اجراکننده آزمایشی می‌تواند به شی IConfiguration که بخشی از آن است و در آن اجرا می‌شود دسترسی داشته باشد. برای جزئیات بیشتر به توضیحات جسم پیکربندی مراجعه کنید.

برای اجرای اجرای آزمایشی، باید IConfigurationReceiver را برای دریافت شیء IConfiguration پیاده سازی کنید.

دونده تست انعطاف پذیر

دونده های آزمایشی اگر کنترل دانه ای روی آن ها داشته باشند، می توانند روشی انعطاف پذیر برای اجرای تست های خود ارائه دهند، به عنوان مثال، دونده تست JUnit می تواند هر تست واحد را به صورت جداگانه اجرا کند.

این امر به مهار و زیرساخت بزرگتر اجازه می دهد تا از آن کنترل دقیق استفاده کند و کاربران بتوانند تا حدی از طریق فیلتر کردن ، دونده آزمایشی را اجرا کنند.

پشتیبانی از فیلتر کردن در رابط ITestFilterReceiver توضیح داده شده است، که اجازه می دهد مجموعه هایی از فیلترهای include و exclude برای آزمایش هایی که باید یا نباید اجرا شوند دریافت کنید.

قرارداد ما این است که آزمایشی اجرا می شود اگر با یک یا چند فیلتر شامل مطابقت داشته باشد و با هیچ یک از فیلترهای حذف مطابقت ندارد. اگر فیلترهای شامل ارائه نشده باشد، همه آزمایش‌ها باید تا زمانی اجرا شوند که با هیچ یک از فیلترهای حذف مطابقت نداشته باشند.

توجه: ما دوندگان آزمایشی را تشویق می‌کنیم که به گونه‌ای نوشته شوند که از این فیلترینگ پشتیبانی کند، زیرا ارزش افزوده زیادی در زیرساخت‌های بزرگ‌تر ایجاد می‌کند. اما ما درک می کنیم که در برخی موارد انجام این کار ممکن نیست.