تنظیمات تست پیشرفته

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

• تست‌های ابزاری را فقط برای یک نوع ساخت خاص اجرا کنید یا تنظیمات مانیفست آن را لغو کنید.
• نوع ساختی که تست‌هایتان روی آن اجرا می‌شوند را تغییر دهید یا گزینه‌های Gradle آن را پیکربندی کنید.
• تست‌های ابزار دقیق خود را در ماژول تست خودشان استخراج کنید.
• آزمایش‌های پیشرفته‌تری را به عنوان بخشی از تنظیمات یکپارچه‌سازی مداوم خود انجام دهید.

این صفحه روش‌های مختلفی را برای پیکربندی تست‌های شما در زمانی که تنظیمات پیش‌فرض با نیازهای شما مطابقت ندارند، شرح می‌دهد.

یک تست ابزاری برای یک نوع ساخت ایجاد کنید

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

برای پیوند دادن تست‌های ابزاربندی‌شده به یک نسخهٔ ساخت‌یافته، آن‌ها را در مجموعهٔ منبع خودشان، واقع در src/androidTest VariantName ، قرار دهید.

Instrumented tests in the src/androidTest/ source set are shared by all build variants. When building a test APK for the "MyFlavor" variant of your app, Gradle combines the src/androidTest/ and src/androidTestMyFlavor/ source sets.

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

1. در پنجره پروژه ، روی منو کلیک کنید و نمای پروژه را انتخاب کنید.
2. در پوشه ماژول مربوطه، روی پوشه src کلیک راست کرده و روی New > Directory کلیک کنید.
3. For the directory name, enter "androidTest VariantName ." For example, if you have a build variant called "MyFlavor," use the directory name androidTestMyFlavor .
4. روی تأیید کلیک کنید.
5. روی دایرکتوری جدید کلیک راست کرده و New > Directory را انتخاب کنید.
6. «java» را به عنوان نام دایرکتوری وارد کنید، سپس روی تأیید کلیک کنید.

اکنون می‌توانید با دنبال کردن مراحل افزودن یک تست جدید، تست‌هایی را به این مجموعه منبع جدید اضافه کنید. وقتی به کادر محاوره‌ای Choose Destination Directory رسیدید، مجموعه منبع تست نوع جدید را انتخاب کنید.

جدول زیر مثالی از چگونگی قرارگیری فایل‌های تست ابزار دقیق در مجموعه‌های منبعی که با مجموعه‌های منبع کد برنامه مطابقت دارند را نشان می‌دهد:

جدول 1. کد منبع برنامه و فایل‌های تست ابزار دقیق مربوطه

مسیر به کلاس برنامه	مسیر تطبیق کلاس تست ابزار دقیق
src/main/kotlin+java/Example.kt	src/androidTest/java/AndroidExampleTest.kt
src/myFlavor/kotlin+java/Example.kt	src/androidTestMyFlavor/java/AndroidExampleTest.kt

Just as it does for your app source sets, the Gradle build merges and overrides files from different test source sets. In this case, the AndroidExampleTest.kt file in the androidTestMyFlavor source set overrides the version in the androidTest source set. This is because the product flavor source set has priority over the main source set.

وقتی در انتخابگر build variants، نسخه‌های مختلفی را انتخاب می‌کنید، پوشه‌های androidTest مناسب در نمای اندروید نمایش داده می‌شوند تا پوشه‌های مورد استفاده را نشان دهند:

شکل ۱. گونه‌ی MyFlavor انتخاب شده است؛ پوشه‌ی androidTestMyFlavor در نمای اندروید نمایش داده می‌شود.

پوشه androidTestMyFlavor هنگام انتخاب نوع دیگری نشان داده نمی‌شود:

شکل ۲. نوع OtherFlavor انتخاب شده است؛ پوشه androidTestMyFlavor در نمای اندروید نمایش داده نمی‌شود.

اگر از نمای پروژه استفاده کنید، این کمی متفاوت به نظر می‌رسد، اما اصل کار یکسان است:

شکل ۳. گونه‌ی MyFlavor انتخاب شده است؛ پوشه‌ی androidTestMyFlavor در نمای پروژه فعال است.

وقتی نوع دیگری انتخاب می‌شود، پوشه androidTestMyFlavor هنوز قابل مشاهده است، اما به عنوان فعال نشان داده نمی‌شود:

شکل ۴. نوع OtherFlavor انتخاب شده است؛ پوشه androidTestMyFlavor در نمای پروژه فعال نیست.

برای اطلاعات بیشتر در مورد نحوه ادغام مجموعه‌های منبع، به مجموعه‌های منبع مراجعه کنید.

تنظیمات مانیفست ابزار دقیق را پیکربندی کنید

Instrumented tests are built into a separate APK with its own AndroidManifest.xml file. When Gradle builds your test APK, it automatically generates the AndroidManifest.xml file and configures it with the <instrumentation> node. One of the reasons Gradle configures this node for you is to make sure that the targetPackage property specifies the correct package name of the app under test.

برای تغییر سایر تنظیمات این گره، یا یک فایل مانیفست دیگر در مجموعه منبع تست ایجاد کنید یا فایل build.gradle سطح ماژول خود را پیکربندی کنید، همانطور که در نمونه کد زیر نشان داده شده است. لیست کامل گزینه‌ها را می‌توانید در مرجع API BaseFlavor بیابید.

کاتلین

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

گرووی

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

هر طعم محصولی که پیکربندی می‌کنید می‌تواند ویژگی‌های موجود در بلوک defaultConfig {} را لغو کند. برای کسب اطلاعات بیشتر، به پیکربندی طعم‌های محصول بروید.

ویژگی‌های موجود در قطعه کد عبارتند از:

تنظیم	توضیحات
testApplicationId	شناسه برنامه را برای APK آزمایشی مشخص می‌کند.
testInstrumentationRunner	نام کلاس کاملاً واجد شرایطِ اجراکننده‌ی ابزار دقیقِ تست را مشخص می‌کند.
testHandleProfiling	اگر روی true تنظیم شود، کلاس instrumentation را قادر می‌سازد تا پروفایل‌بندی را شروع و متوقف کند. اگر روی false تنظیم شود، پروفایلینگ در تمام مدت اجرای کلاس instrumentation رخ می‌دهد.
testFunctionalTest	اگر روی true تنظیم شود، نشان می‌دهد که سیستم اندروید باید کلاس instrumentation را به عنوان یک تست عملکردی اجرا کند. مقدار پیش‌فرض false است.

Change the test build type

به طور پیش‌فرض، تمام تست‌های instrumentation در برابر نوع ساخت debug اجرا می‌شوند. شما می‌توانید با استفاده از ویژگی testBuildType در فایل build.gradle سطح ماژول خود، این را به نوع ساخت دیگری تغییر دهید. برای مثال، اگر می‌خواهید تست‌های خود را در برابر نوع ساخت staging خود اجرا کنید، فایل را مطابق قطعه کد زیر ویرایش کنید:

کاتلین

android {
    ...
    testBuildType = "staging"
}

گرووی

android {
    ...
    testBuildType "staging"
}

Configure Gradle test options

The Android Gradle plugin lets you specify certain options for all or just some of your tests. In the module-level build.gradle file, use the testOptions block to specify options that change how Gradle runs all your tests:

کاتلین

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir = "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

گرووی

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

The reportDir property changes the directory where Gradle saves test reports. By default, Gradle saves test reports in the path_to_your_project / module_name /build/outputs/reports/ directory. $rootDir sets the path relative to the root directory of the current project.

The resultsDir property changes the directory where Gradle saves test results. By default, Gradle saves test results in the path_to_your_project / module_name /build/outputs/test-results/ directory. $rootDir sets the path relative to the root directory of the current project.

برای تعیین گزینه‌ها فقط برای تست‌های واحد محلی، بلوک unitTests را درون testOptions پیکربندی کنید.

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

گرووی

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

به طور پیش‌فرض، تست‌های واحد محلی هر زمان که کدی که آزمایش می‌کنید سعی در دسترسی به APIهای پلتفرم اندروید داشته باشد، یک استثنا ایجاد می‌کنند، مگر اینکه خودتان وابستگی‌های اندروید را شبیه‌سازی کنید یا از یک چارچوب تست مانند Mockito استفاده کنید. با این حال، می‌توانید ویژگی returnDefaultValues فعال کنید تا تست هنگام دسترسی به APIهای پلتفرم، به جای ایجاد یک استثنا، مقدار null یا zero را برگرداند.

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

ویژگی jvmArgs آرگومان(های) JVM را برای JVM(های) آزمایشی تنظیم می‌کند.

همچنین می‌توانید نام وظیفه را بررسی کنید تا گزینه‌ها فقط برای تست‌هایی که مشخص می‌کنید اعمال شوند. در قطعه کد مثال، ویژگی debug روی true تنظیم شده است، اما فقط برای وظیفه testDebugUnitTest .

برای تست‌های ابزاری از ماژول‌های تست جداگانه استفاده کنید

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

برای ایجاد یک ماژول آزمایشی، مراحل زیر را دنبال کنید:

1. یک ماژول کتابخانه ایجاد کنید .
2. در فایل build.gradle در سطح ماژول، به جای com.android.library افزونه com.android.test را اعمال کنید.
3. Click Sync Project .

پس از ایجاد ماژول آزمایشی، می‌توانید کد آزمایشی خود را در مجموعه منبع اصلی یا متغیر (برای مثال، src/main/kotlin+java یا src/ variant /kotlin+java ) قرار دهید. اگر ماژول برنامه شما چندین طعم محصول را تعریف می‌کند، می‌توانید آن طعم‌ها را در ماژول آزمایشی خود دوباره ایجاد کنید. با استفاده از مدیریت وابستگی آگاه از نوع ، ماژول آزمایشی تلاش می‌کند طعم منطبق را در ماژول هدف آزمایش کند.

By default, test modules contain and test only a debug variant. However, you can create new build types to match the tested app project. To make the test module test a different build type and not the debug one, use VariantFilter to disable the debug variant in the test project, as shown:

کاتلین

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

گرووی

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

If you want a test module to target only certain flavors or build types of an app, you can use the matchingFallbacks property to target only the variants you want to test. This also prevents the test module from having to configure those variants for itself.