تست در اندروید استودیو و تست از خط فرمان نحوه تنظیم و اجرای تنظیمات اولیه تست را توضیح می دهد. با این حال، وقتی برنامه شما و الزامات آزمایشی آن پیشرفتهتر میشوند، ممکن است لازم باشد تنظیمات آزمایشی خود را بیشتر تطبیق دهید. برای مثال، زمانی که میخواهید کارهای زیر را انجام دهید، ممکن است به تنظیمات آزمایشی پیشرفته نیاز داشته باشید:
- تست های ابزاری را فقط برای یک نوع ساخت خاص اجرا کنید یا تنظیمات مانیفست آن را لغو کنید.
- نوع ساختی را که آزمایشهای شما با آن اجرا میشود تغییر دهید یا گزینههای Gradle آن را پیکربندی کنید.
- تست های ابزاری خود را در ماژول تست خود استخراج کنید.
- تست های پیشرفته تری را به عنوان بخشی از راه اندازی Continuous Integration انجام دهید.
در این صفحه روشهای مختلفی برای پیکربندی تستهای شما در زمانی که تنظیمات پیشفرض با نیازهای شما مطابقت ندارند، توضیح میدهد.
یک تست ابزاری برای یک نوع ساخت ایجاد کنید
اگر پروژه شما شامل انواع ساخت با مجموعههای منبع منحصر به فرد است، ممکن است بخواهید تستهای ابزاری را که با آن مجموعههای منبع مطابقت دارند، اضافه کنید. این کد تست شما را سازماندهی میکند و به شما امکان میدهد فقط آزمایشهایی را اجرا کنید که برای یک نوع ساخت معین اعمال میشوند.
برای پیوند دادن تستهای ابزاردار به یک نوع ساخت، آنها را در مجموعه منبع خود، واقع در src/androidTest VariantName
قرار دهید.
تست های ابزاری در مجموعه منبع src/androidTest/
توسط همه انواع ساخت به اشتراک گذاشته می شود. هنگام ساختن یک APK آزمایشی برای نوع «MyFlavor» برنامهتان، Gradle مجموعههای منبع src/androidTest/
و src/androidTestMyFlavor/
را ترکیب میکند.
برای افزودن یک مجموعه منبع آزمایشی برای نوع ساخت خود در Android Studio، این مراحل را دنبال کنید:
- در پنجره Project ، روی منو کلیک کرده و نمای پروژه را انتخاب کنید.
- در پوشه ماژول مناسب، روی پوشه src کلیک راست کرده و New > Directory را کلیک کنید.
- برای نام دایرکتوری، "androidTest VariantName " را وارد کنید. به عنوان مثال، اگر یک نوع ساخت به نام "MyFlavor" دارید، از نام دایرکتوری
androidTestMyFlavor
استفاده کنید. - روی OK کلیک کنید.
- روی فهرست جدید کلیک راست کرده و New > Directory را انتخاب کنید.
- "java" را به عنوان نام دایرکتوری وارد کنید، سپس روی OK کلیک کنید.
اکنون میتوانید با دنبال کردن مراحل افزودن یک آزمایش جدید، آزمایشهایی را به مجموعه منبع جدید اضافه کنید. وقتی به گفتگوی Choose Destination Directory رسیدید، مجموعه منبع آزمایشی جدید را انتخاب کنید.
جدول زیر نمونهای از نحوه قرارگیری فایلهای تست ابزار دقیق در مجموعههای منبعی را نشان میدهد که با مجموعههای منبع کد برنامه مطابقت دارند:
مسیر رسیدن به کلاس برنامه | مسیر کلاس تست ابزار دقیق |
---|---|
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 نمایش داده میشوند تا پوشههای مورد استفاده را نشان دهند:
پوشه 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:
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
.
از ماژول های تست جداگانه برای تست های ابزار دقیق استفاده کنید
اگر میخواهید یک ماژول اختصاصی برای تستهای ابزاری داشته باشید، برای جداسازی بقیه کدها از تستهایتان، یک ماژول تست جداگانه ایجاد کنید و ساختار آن را شبیه به ماژول کتابخانه پیکربندی کنید.
برای ایجاد یک ماژول تست به صورت زیر عمل کنید:
- یک ماژول کتابخانه ایجاد کنید .
- در فایل
build.gradle
سطح ماژول، افزونهcom.android.test
را به جایcom.android.library
اعمال کنید. - روی همگام سازی پروژه کلیک کنید .
بعد از اینکه ماژول آزمایشی خود را ایجاد کردید، می توانید کد آزمایشی خود را در مجموعه منبع اصلی یا متغیر قرار دهید (به عنوان مثال، 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
برای هدف قرار دادن تنها انواعی که میخواهید آزمایش کنید استفاده کنید. این همچنین باعث می شود که ماژول تست مجبور نباشد آن گونه ها را برای خود پیکربندی کند.