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

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

  • تست های ابزاری را فقط برای یک نوع ساخت خاص اجرا کنید یا تنظیمات مانیفست آن را لغو کنید.
  • نوع ساختی را که آزمایش‌های شما با آن اجرا می‌شود تغییر دهید یا گزینه‌های 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 کلیک کنید.

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

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

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

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

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

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

نوع MyFlavor انتخاب شده و پوشه androidTestMyFlavor در نمای Android نشان داده می شود
شکل 1. نوع MyFlavor انتخاب شده است. پوشه androidTestMyFlavor در نمای اندروید نمایش داده می شود.

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

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

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

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

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

نوع OtherFlavor انتخاب شده و پوشه androidTestMyFlavor در نمای پروژه فعال نیست
شکل 4. نوع OtherFlavor انتخاب شده است. پوشه 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:

Setting Description
testApplicationId Specifies the application ID for the test APK.
testInstrumentationRunner Specifies the fully qualified class name of the test instrumentation runner.
testHandleProfiling If set to true, enables the instrumentation class to start and stop profiling.
If set to false, profiling occurs the entire time the instrumentation class is running.
testFunctionalTest If set to true, indicates that the Android system should run the instrumentation class as a functional test.
The default value is false.

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:

Groovy

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 برای هدف قرار دادن تنها انواعی که می‌خواهید آزمایش کنید استفاده کنید. این همچنین باعث می شود که ماژول تست مجبور نباشد آن گونه ها را برای خود پیکربندی کند.