از تست دوبل در اندروید استفاده کنید

وقتی یک عنصر یا سیستمی از عناصر را آزمایش می کنید، این کار را به صورت مجزا انجام می دهید. برای مثال، برای آزمایش ViewModel، نیازی به راه‌اندازی شبیه‌ساز و راه‌اندازی یک رابط کاربری ندارید، زیرا به چارچوب اندروید بستگی ندارد (یا نباید).

با این حال، موضوع مورد آزمایش ممکن است برای کارکرد آن به دیگران بستگی داشته باشد . به عنوان مثال، یک ViewModel ممکن است به یک مخزن داده برای کار بستگی داشته باشد.

زمانی که نیاز به ایجاد وابستگی به موضوع مورد آزمایش دارید، یک روش معمول ایجاد یک تست دوبل (یا شیء آزمایشی ) است. دوبل های تست اشیایی هستند که به عنوان اجزای برنامه شما به نظر می رسند و عمل می کنند اما در آزمایش شما برای ارائه یک رفتار یا داده خاص ایجاد شده اند. مزایای اصلی این است که آنها تست های شما را سریع تر و ساده تر می کنند.

انواع تست دوبل

انواع مختلف تست دوبل وجود دارد:

مثال استفاده از جعلی

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

object FakeUserRepository : UserRepository {
    fun getUsers() = listOf(UserAlice, UserBob)
}

val const UserAlice = User("Alice")
val const UserBob = User("Bob")

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

آزمایش زیر تأیید می کند که ViewModel به درستی اولین نام کاربری را در معرض دید قرار می دهد.

@Test
fun viewModelA_loadsUsers_showsFirstUser() {
    // Given a VM using fake data
    val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init

    // Verify that the exposed data is correct
    assertEquals(viewModel.firstUserName, UserAlice.name)
}

جایگزین کردن UserRepository با یک جعلی در تست واحد آسان است، زیرا ViewModel توسط تستر ایجاد می‌شود. با این حال، جایگزینی عناصر دلخواه در آزمایش های بزرگتر می تواند چالش برانگیز باشد.

جایگزینی اجزا و تزریق وابستگی

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

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

شما می توانید برنامه خود را طوری طراحی کنید که به این انعطاف پذیری دستی دست یابد، اما توصیه می کنیم از یک چارچوب تزریق وابستگی مانند Hilt برای جایگزینی اجزای برنامه خود در زمان تست استفاده کنید. راهنمای تست Hilt را ببینید.

مراحل بعدی

صفحه استراتژی‌های تست نشان می‌دهد که چگونه می‌توانید بهره‌وری خود را با استفاده از انواع مختلف تست‌ها افزایش دهید.