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

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

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

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

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

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

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

تست های ابزاری در مجموعه منبع src/androidTest/ توسط همه انواع ساخت به اشتراک گذاشته می شود. هنگام ساختن یک APK آزمایشی برای نوع «MyFlavor» برنامه‌تان، Gradle مجموعه‌های منبع src/androidTest/ و src/androidTestMyFlavor/ را ترکیب می‌کند.

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

1. در پنجره Project ، روی منو کلیک کرده و نمای پروژه را انتخاب کنید.
2. در پوشه ماژول مناسب، روی پوشه src کلیک راست کرده و روی New > Directory کلیک کنید.
3. برای نام دایرکتوری، "androidTest VariantName " را وارد کنید. برای مثال، اگر یک نوع ساخت به نام MyFlavor دارید، از نام دایرکتوری androidTestMyFlavor استفاده کنید.
4. روی OK کلیک کنید.
5. روی فهرست جدید کلیک راست کرده و New > Directory را انتخاب کنید.
6. "java" را به عنوان نام دایرکتوری وارد کنید، سپس روی OK کلیک کنید.

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

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

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

همانطور که برای مجموعه های منبع برنامه شما انجام می دهد، ساخت Gradle فایل ها را از مجموعه های مختلف منبع آزمایشی ادغام و لغو می کند. در این حالت، فایل AndroidExampleTest.java در مجموعه منبع androidTestMyFlavor نسخه موجود در مجموعه منبع androidTest را لغو می کند. این به این دلیل است که مجموعه منبع طعم محصول بر مجموعه منبع اصلی اولویت دارد.

هنگامی که طعم‌های مختلف را در انتخابگر انواع ساخت انتخاب می‌کنید، پوشه‌های androidTest مناسب در نمای Android نمایش داده می‌شوند تا پوشه‌های استفاده شده را نشان دهند:

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

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

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

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

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

تست‌های ابزاری در یک APK جداگانه با فایل AndroidManifest.xml خود ساخته شده‌اند. وقتی Gradle APK آزمایشی شما را می‌سازد، به طور خودکار فایل AndroidManifest.xml را تولید می‌کند و آن را با گره <instrumentation> پیکربندی می‌کند. یکی از دلایلی که Gradle این گره را برای شما پیکربندی می کند این است که مطمئن شوید ویژگی targetPackage نام بسته صحیح برنامه تحت آزمایش را مشخص می کند.

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

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
    }
}

Each product flavor you configure can override properties in the defaultConfig {} block. To learn more, go to Configure product flavors.

The properties in the snippet are:

Change the test build type

By default, all instrumentation tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your staging build type, edit the file as shown in the following snippet:

android {
    ...
    testBuildType "staging"
}

android {
    ...
    testBuildType = "staging"
}

گزینه های تست Gradle را پیکربندی کنید

افزونه Android Gradle به شما امکان می دهد گزینه های خاصی را برای همه یا فقط برخی از تست های خود مشخص کنید. در فایل build.gradle در سطح ماژول، از بلوک testOptions برای تعیین گزینه‌هایی استفاده کنید که نحوه اجرای همه آزمایش‌های شما را تغییر می‌دهند:

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"
    }
}

ویژگی reportDir دایرکتوری را تغییر می دهد که Gradle گزارش های تست را در آن ذخیره می کند. به‌طور پیش‌فرض، Gradle گزارش‌های آزمایشی را در path_to_your_project / module_name /build/outputs/reports/ ذخیره می‌کند. $rootDir مسیر را نسبت به دایرکتوری ریشه پروژه فعلی تنظیم می کند.

ویژگی resultsDir دایرکتوری را تغییر می دهد که Gradle نتایج آزمایش را در آن ذخیره می کند. به طور پیش فرض، Gradle نتایج آزمایش را در path_to_your_project / module_name /build/outputs/test-results/ ذخیره می کند. $rootDir مسیر را نسبت به دایرکتوری ریشه پروژه فعلی تنظیم می کند.

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

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

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

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

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")
                }
                ...
            }
        }
    }
}

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

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

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

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

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

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

برای ایجاد یک ماژول تست به صورت زیر عمل کنید:

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

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

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

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

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

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