این صفحه اصول اصلی آزمایش برنامههای Android، ازجمله روالهای مطلوب مرکزی و مزایای آنها را شرح میدهد.
مهارتهای Android
مشاهده در GitHubایجاد یک استراتژی آزمایش
android skills add testing-setupمزایای آزمایش کردن
آزمایش کردن بخش جداییناپذیر فرایند توسعه برنامه است. با اجرای مداوم آزمایشها روی برنامهتان، میتوانید صحت، رفتار عملکردی، و قابلیت استفاده برنامهتان را قبلاز انتشار عمومی آن تأیید کنید.
میتوانید با پیمایش در برنامه، آن را بهصورت دستی آزمایش کنید. ممکن است از دستگاهها و شبیهسازهای مختلفی استفاده کنید، زبان سیستم را تغییر دهید، و سعی کنید همه خطاهای کاربر را ایجاد کنید یا همه جریانهای کاربر را طی کنید.
بااینحال، آزمایش دستی مقیاسپذیری ضعیفی دارد و ممکن است بهراحتی از پسرفتهای رفتار برنامهتان غافل شوید. آزمایش خودکار شامل استفاده از ابزارهایی است که آزمایشها را برای شما انجام میدهند، که سریعتر و تکرارپذیرتر است و معمولاً بازخورد قابلاجراتری درباره برنامهتان در مراحل اولیه فرایند توسعه به شما ارائه میدهد.
انواع آزمایشها در Android
برنامههای تلفن همراه پیچیده هستند و باید در محیطهای زیادی بهخوبی کار کنند. به همین دلیل، انواع مختلفی از آزمایشها وجود دارد.
موضوع
برای مثال، بسته به موضوع، انواع مختلفی از آزمایشها وجود دارد:
- آزمایش کارکردی: آیا برنامهام کاری را که باید انجام میدهد؟
- آزمایش عملکرد: آیا این کار را سریع و کارآمد انجام میدهد؟
- آزمایش دسترسپذیری: آیا با خدمات دسترسپذیری بهخوبی کار میکند؟
- آزمایش سازگاری: آیا در همه دستگاهها و سطوح API بهخوبی کار میکند؟
حوزه
آزمایشها همچنین بسته به اندازه یا درجه جداسازی متفاوت هستند:
- آزمایشهای واحد یا آزمایشهای کوچک فقط بخش بسیار کوچکی از برنامه را درستیسنجی میکنند، مثل یک روش یا کلاس.
- آزمایشهای سرتاسر یا آزمایشهای بزرگ بخشهای بزرگتر برنامه را بهطور همزمان درستیسنجی میکنند، مثلاً کل صفحهنمایش یا جریان کاربر.
- آزمایشهای متوسط در بین این دو قرار دارند و ادغام بین دو یا چند واحد را بررسی میکنند.
راههای زیادی برای طبقهبندی آزمایشها وجود دارد. بااینحال، مهمترین تفاوت برای توسعهدهندگان نرمافزار این است که آزمایشها کجا اجرا میشوند.
آزمایشهای ابزاردار درمقابل آزمایشهای محلی
میتوانید آزمایشها را در دستگاه Android یا رایانه دیگری اجرا کنید:
- آزمایشهای ابزاردار در دستگاه Android، چه فیزیکی یا شبیهسازیشده، اجرا میشوند. برنامه در کنار برنامه آزمایشی ساخته و نصب میشود که فرمانها را تزریق میکند و وضعیت را میخواند. آزمایشهای ابزاردار معمولاً آزمایشهای میانای کاربر هستند که برنامهای را راهاندازی میکنند و سپس با آن تعامل برقرار میکنند.
- آزمایشهای محلی در ماشین توسعه نرمافزار یا سرور شما اجرا میشوند، بنابراین به آنها آزمایشهای سمت میزبان نیز گفته میشود. این آزمونها معمولاً کوچک و سریع هستند و موضوع تحت آزمایش را از بقیه برنامه جدا میکنند.
همه آزمایشهای واحد محلی نیستند و همه آزمایشهای سرتاسر در دستگاه اجرا نمیشوند. برای مثال:
- آزمایش محلی بزرگ: میتوانید از شبیهساز Android که بهصورت محلی اجرا میشود، مانند Robolectric، استفاده کنید.
- آزمایش ابزاردار کوچک: میتوانید تأیید کنید که کدتان با ویژگی چارچوب، مثل پایگاه داده SQLite، بهخوبی کار میکند. میتوانید این آزمایش را در چندین دستگاه اجرا کنید تا ادغام با چندین نسخه SQLite را بررسی کنید.
مثالها
قطعههای زیر نحوه تعامل با میانای کاربر را در آزمایش میانای کاربر ابزاردار نشان میدهند که روی یک عنصر کلیک میکند و درستیسنجی میکند که عنصر دیگری نمایش داده میشود.
اسپرسو
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Compose UI
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
این قطعه کد بخشی از یک آزمون واحد برای ViewModel (آزمون محلی، سمت میزبان) را نشان میدهد:
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
معماری قابلآزمایش
با معماری برنامه قابلآزمایش، کد از ساختاری پیروی میکند که به شما امکان میدهد بهراحتی بخشهای مختلف آن را بهصورت مجزا آزمایش کنید. معماریهای قابلآزمایش مزایای دیگری نیز دارند، ازجمله خوانایی بهتر، قابلیت نگهداری، مقیاسپذیری، و قابلیت استفاده مجدد.
معماریای که قابلآزمایش نباشد موارد زیر را تولید میکند:
- آزمایشهای بزرگتر، کندتر، و ناپایدارتر. کلاسهایی که نمیتوانند واحدآزمایی شوند ممکن است باید با آزمایشهای ادغام بزرگتر یا آزمایشهای واسط کاربر پوشش داده شوند.
- فرصتهای کمتر برای آزمایش سناریوهای مختلف. آزمایشهای بزرگتر کندتر هستند، بنابراین آزمایش کردن همه حالتهای ممکن برنامه ممکن است غیرواقعی باشد.
برای کسب اطلاعات بیشتر درباره رهنمودهای معماری، به راهنمای معماری برنامه مراجعه کنید.
رویکردهای جداسازی
اگر بتوانید بخشی از تابع، کلاس، یا ماژول را از بقیه استخراج کنید، آزمایش کردن آن آسانتر و مؤثرتر خواهد بود. به این کار جداسازی میگویند و مهمترین مفهوم در معماری قابلآزمایش است.
روشهای رایج جداسازی شامل موارد زیر است:
- برنامه را به لایههایی مثل «ارائه»، «دامنه»، و «داده» تقسیم کنید. همچنین میتوانید برنامه را به ماژولهایی تقسیم کنید، هر ماژول برای یک ویژگی.
- از افزودن منطق به هستارهایی که وابستگیهای بزرگ دارند، مانند فعالیتها و قطعهها، خودداری کنید. از این کلاسها بهعنوان نقاط ورودی به چارچوب استفاده کنید و منطق کسبوکار و واسط کاربر را به جای دیگری، مثل Composable، ViewModel، یا لایه دامنه منتقل کنید.
- از وابستگیهای چارچوب مستقیم در کلاسهای حاوی منطق کسبوکار اجتناب کنید. برای مثال، از Android Contexts در ViewModels استفاده نکنید.
- وابستگیها را بهراحتی جایگزین کنید. برای مثال، از میاناهای بهجای پیادهسازیهای واقعی استفاده کنید. از تزریق وابستگی استفاده کنید، حتی اگر از چارچوب تزریق وابستگی استفاده نمیکنید.
مراحل بعدی
اکنون که میدانید چرا باید آزمایش کنید و با دو نوع اصلی آزمایش آشنا شدید، میتوانید چه چیزی را آزمایش کنید یا درباره راهبردهای آزمایش بیشتر بدانید
یا اگر میخواهید اولین آزمایشتان را ایجاد کنید و با انجام دادن یاد بگیرید، آزمایش کردن codelabs را بررسی کنید.