Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedef alan testlerden çok da farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulamayla aynı sertifikayla imzalanması gerektiğini belirtmekte fayda var.
Bu kılavuzun, platform kaynak ağacı iş akışı hakkında zaten bir miktar bilgiye sahip olduğunuzu varsaydığını unutmayın. Değilse lütfen Gereksinimler'e bakın. Burada ele alınan örnek, kendi test uygulama paketinde belirlenen hedef paketle yeni bir enstrümantasyon testi yazmaktır. Konsepte yabancıysanız lütfen Platform testi girişini okuyun.
Bu kılavuz örnek olarak aşağıdaki testi kullanır:
- çerçeveler/temel/paketler/Kabuk/testler
Devam etmeden önce kaba bir izlenim edinmek için önce koda göz atmanız önerilir.
Kaynak konumuna karar verin
Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, kural, test kaynak kodunu platform kaynak ağacındaki bileşen kaynak dizininizin kökü altındaki bir tests
dizinine yerleştirmektir.
Kendi kendini test eden testlere yönelik uçtan uca örnekte kaynak konumu hakkında daha fazla tartışmaya bakın.
Bildirim dosyası
Normal bir uygulamada olduğu gibi, her enstrümantasyon test modülünün bir bildirim dosyasına ihtiyacı vardır. Dosyayı AndroidManifest.xml
olarak adlandırırsanız ve test modülünüz için Android.mk
yanında sağlarsanız, BUILD_PACKAGE
çekirdek makefile tarafından otomatik olarak dahil edilecektir.
Daha fazla ilerlemeden önce Uygulama Bildirimine Genel Bakış'ı incelemeniz önemle tavsiye edilir.
Bu, bir bildirim dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sunar.
Örnek gerrit değişikliğine ilişkin bildirim dosyasının en son sürümüne şu adresten erişilebilir: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml
Kolaylık sağlamak için buraya bir anlık görüntü eklenmiştir:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
<application>
<uses-library android:name="android.test.runner" />
<activity
android:name="com.android.shell.ActionSendMultipleConsumerActivity"
android:label="ActionSendMultipleConsumer"
android:theme="@android:style/Theme.NoDisplay"
android:noHistory="true"
android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.SEND_MULTIPLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="*/*" />
</intent-filter>
</activity>
</application>
<instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
android:targetPackage="com.android.shell"
android:label="Tests for Shell" />
</manifest>
Bildiri dosyasındaki bazı seçilmiş açıklamalar:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
package
niteliği, uygulama paketinin adıdır: Bu, Android uygulama çerçevesinin bir uygulamayı (veya bu bağlamda: test uygulamanızı) tanımlamak için kullandığı benzersiz tanımlayıcıdır. Sistemdeki her kullanıcı o paket adı ile yalnızca bir uygulama kurabilir.
Bu bir test uygulama paketi olduğundan, test edilen uygulama paketinden bağımsız olarak farklı bir paket adı kullanılmalıdır: yaygın bir kural, .test
son ekinin eklenmesidir.
Ayrıca, bu package
niteliği ComponentName#getPackageName()
işlevinin döndürdüğü öznitelikle aynıdır ve ayrıca adb shell
aracılığıyla çeşitli pm
alt komutlarıyla etkileşimde bulunmak için kullanacağınız öznitelikle aynıdır.
Ayrıca paket adının genellikle Java paket adıyla aynı tarzda olmasına rağmen aslında onunla çok az ilgisi olduğunu lütfen unutmayın. Başka bir deyişle, uygulama (veya test) paketiniz herhangi bir paket adına sahip sınıflar içerebilir, ancak diğer yandan basitliği tercih edebilir ve üst düzey Java paket adınızı uygulamanızda veya testinizde uygulama paket adıyla aynı tutabilirsiniz.
<uses-library android:name="android.test.runner" />
İlgili sınıflar ayrı bir çerçeve jar kitaplığı dosyasında paketlendiğinden bu, tüm Enstrümantasyon testleri için gereklidir, dolayısıyla test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerektirir.
android:targetPackage="com.android.shell"
Bu, enstrümantasyonun hedef paketini com.android.shell
olarak ayarlar. Enstrümantasyon am instrument
komutu aracılığıyla çağrıldığında, çerçeve com.android.shell
işlemini yeniden başlatır ve testin yürütülmesi için enstrümantasyon kodunu sürece enjekte eder. Bu aynı zamanda test kodunun, test altındaki uygulamada çalışan tüm sınıf örneklerine erişebileceği ve açığa çıkan test kancalarına bağlı olarak durumu değiştirebileceği anlamına da gelir.
Basit yapılandırma dosyası
Her yeni test modülü, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyasına sahip olmalıdır. Çoğu durumda Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması'na bakın.
Karmaşık yapılandırma dosyası
Daha karmaşık testler için, Android'in test koşum takımı Trade Federasyonu için bir test yapılandırma dosyası da yazmanız gerekir.
Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.
Örnek gerrit değişikliğine ilişkin yapılandırma dosyasının en son sürümüne şuradan erişilebilir: frameworks/base/packages/Shell/tests/AndroidTest.xml
Kolaylık sağlamak için buraya bir anlık görüntü eklenmiştir:
<configuration description="Runs Tests for Shell.">
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk" />
</target_preparer>
<option name="test-suite-tag" value="apct" />
<option name="test-tag" value="ShellTests" />
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="com.android.shell.tests" />
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
</test>
</configuration>
Test yapılandırma dosyasındaki bazı seçilmiş açıklamalar:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Bu, Ticaret Federasyonuna, belirtilen bir target_preparer kullanarak ShellTests.apk dosyasını hedef cihaza yüklemesini söyler. Ticaret Federasyonu'nda geliştiricilerin kullanabileceği çok sayıda hedef hazırlayıcı vardır ve bunlar, testin yürütülmesinden önce cihazın doğru şekilde kurulduğundan emin olmak için kullanılabilir.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="com.android.shell.tests"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Bu, testi yürütmek için kullanılacak Ticaret Federasyonu test sınıfını ve yürütülecek cihazdaki pakette geçenleri ve bu durumda JUnit olan test çalıştırıcı çerçevesini belirtir.
Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın
JUnit4 özellikleri
android-support-test
kütüphanesinin test çalıştırıcısı olarak kullanılması, yeni JUnit4 tarzı test sınıflarının benimsenmesine olanak tanır ve örnek gerrit değişikliği, özelliklerinin bazı çok temel kullanımını içerir.
Örnek gerrit değişikliğinin en son kaynak koduna şuradan erişilebilir: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java
Test kalıpları genellikle bileşen ekiplerine özel olsa da, genel olarak bazı faydalı kullanım kalıpları da vardır.
@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
JUnit4'teki önemli bir fark, testlerin artık ortak bir temel test sınıfından miras alınmasının gerekmemesidir; bunun yerine testleri düz Java sınıflarında yazarsınız ve belirli test kurulumunu ve kısıtlamalarını belirtmek için ek açıklamalar kullanırsınız. Bu örnekte bu sınıfın Android JUnit4 testi olarak çalıştırılması gerektiğini anlatıyoruz.
@SmallTest
ek açıklaması, test sınıfının tamamı için bir test boyutu belirledi: bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası sökme ve test sonrası sınıf sökme: JUnit4'teki setUp
ve tearDown
yöntemlerine benzer. Test
açıklaması, gerçek teste açıklama eklemek için kullanılır.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
@Before
ek açıklaması, ön test kurulumunu gerçekleştirmek için JUnit4 tarafından kullanılan yöntemlerde kullanılır. Bu örnekte kullanılmamasına rağmen, test sonrası sökme işlemi için @After
da bulunmaktadır. Benzer şekilde, @BeforeClass
ve @AfterClass
ek açıklamaları, bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve daha sonra sökmek için JUnit4 tarafından kullanılan yöntemlerde kullanılabilir. Sınıf kapsamı kurulumu ve sökme yöntemlerinin statik olması gerektiğini unutmayın.
Test yöntemlerine gelince, JUnit'in önceki sürümünden farklı olarak, artık yöntem adını test
ile başlatmaları gerekmiyor, bunun yerine her birinin @Test
ile açıklanması gerekiyor. Her zamanki gibi, test yöntemleri herkese açık olmalı, dönüş değeri bildirmemeli, parametre almamalı ve istisnalar atabilir.
Context context = InstrumentationRegistry.getTargetContext();
JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden, artık temel sınıf yöntemleri aracılığıyla getContext()
veya getTargetContext()
yoluyla Context
örneklerini elde etmek gerekli değildir; bunun yerine yeni test çalıştırıcısı bunları, enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry
aracılığıyla yönetir. Bu sınıf aracılığıyla şunları da arayabilirsiniz:
-
getInstrumentation()
:Instrumentation
sınıfının örneği -
getArguments()
:am instrument
-e <key> <value>
aracılığıyla aktarılan komut satırı argümanları
Yerel olarak derleyin ve test edin
En yaygın kullanım durumları için Atest'i kullanın.
Daha yoğun özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.
,Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedef alan testlerden çok da farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulamayla aynı sertifikayla imzalanması gerektiğini belirtmekte fayda var.
Bu kılavuzun, platform kaynak ağacı iş akışı hakkında zaten bir miktar bilgiye sahip olduğunuzu varsaydığını unutmayın. Değilse lütfen Gereksinimler'e bakın. Burada ele alınan örnek, kendi test uygulama paketinde belirlenen hedef paketle yeni bir enstrümantasyon testi yazmaktır. Konsepte yabancıysanız lütfen Platform testi girişini okuyun.
Bu kılavuz örnek olarak aşağıdaki testi kullanır:
- çerçeveler/temel/paketler/Kabuk/testler
Devam etmeden önce kaba bir izlenim edinmek için önce koda göz atmanız önerilir.
Kaynak konumuna karar verin
Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, kural, test kaynak kodunu platform kaynak ağacındaki bileşen kaynak dizininizin kökü altındaki bir tests
dizinine yerleştirmektir.
Kendi kendini test eden testlere yönelik uçtan uca örnekte kaynak konumu hakkında daha fazla tartışmaya bakın.
Bildirim dosyası
Normal bir uygulamada olduğu gibi, her enstrümantasyon test modülünün bir bildirim dosyasına ihtiyacı vardır. Dosyayı AndroidManifest.xml
olarak adlandırırsanız ve test modülünüz için Android.mk
yanında sağlarsanız, BUILD_PACKAGE
çekirdek makefile tarafından otomatik olarak dahil edilecektir.
Daha fazla ilerlemeden önce Uygulama Bildirimine Genel Bakış'ı incelemeniz önemle tavsiye edilir.
Bu, bir bildirim dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sunar.
Örnek gerrit değişikliğine ilişkin bildirim dosyasının en son sürümüne şu adresten erişilebilir: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml
Kolaylık sağlamak için buraya bir anlık görüntü eklenmiştir:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
<application>
<uses-library android:name="android.test.runner" />
<activity
android:name="com.android.shell.ActionSendMultipleConsumerActivity"
android:label="ActionSendMultipleConsumer"
android:theme="@android:style/Theme.NoDisplay"
android:noHistory="true"
android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.SEND_MULTIPLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="*/*" />
</intent-filter>
</activity>
</application>
<instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
android:targetPackage="com.android.shell"
android:label="Tests for Shell" />
</manifest>
Bildiri dosyasındaki bazı seçilmiş açıklamalar:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
package
niteliği, uygulama paketinin adıdır: Bu, Android uygulama çerçevesinin bir uygulamayı (veya bu bağlamda: test uygulamanızı) tanımlamak için kullandığı benzersiz tanımlayıcıdır. Sistemdeki her kullanıcı o paket adı ile yalnızca bir uygulama kurabilir.
Bu bir test uygulama paketi olduğundan, test edilen uygulama paketinden bağımsız olarak farklı bir paket adı kullanılmalıdır: yaygın bir kural, .test
son ekinin eklenmesidir.
Ayrıca, bu package
niteliği ComponentName#getPackageName()
işlevinin döndürdüğü öznitelikle aynıdır ve ayrıca adb shell
aracılığıyla çeşitli pm
alt komutlarıyla etkileşimde bulunmak için kullanacağınız öznitelikle aynıdır.
Ayrıca paket adının genellikle Java paket adıyla aynı tarzda olmasına rağmen aslında onunla çok az ilgisi olduğunu lütfen unutmayın. Başka bir deyişle, uygulama (veya test) paketiniz herhangi bir paket adına sahip sınıflar içerebilir, ancak diğer yandan basitliği tercih edebilir ve üst düzey Java paket adınızı uygulamanızda veya testinizde uygulama paket adıyla aynı tutabilirsiniz.
<uses-library android:name="android.test.runner" />
İlgili sınıflar ayrı bir çerçeve jar kitaplığı dosyasında paketlendiğinden bu, tüm Enstrümantasyon testleri için gereklidir, dolayısıyla test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerektirir.
android:targetPackage="com.android.shell"
Bu, enstrümantasyonun hedef paketini com.android.shell
olarak ayarlar. Enstrümantasyon am instrument
komutu aracılığıyla çağrıldığında, çerçeve com.android.shell
işlemini yeniden başlatır ve testin yürütülmesi için enstrümantasyon kodunu sürece enjekte eder. Bu aynı zamanda test kodunun, test altındaki uygulamada çalışan tüm sınıf örneklerine erişebileceği ve açığa çıkan test kancalarına bağlı olarak durumu değiştirebileceği anlamına da gelir.
Basit yapılandırma dosyası
Her yeni test modülü, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyasına sahip olmalıdır. Çoğu durumda Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması'na bakın.
Karmaşık yapılandırma dosyası
Daha karmaşık testler için, Android'in test koşum takımı Trade Federasyonu için bir test yapılandırma dosyası da yazmanız gerekir.
Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.
Örnek gerrit değişikliğine ilişkin yapılandırma dosyasının en son sürümüne şuradan erişilebilir: frameworks/base/packages/Shell/tests/AndroidTest.xml
Kolaylık sağlamak için buraya bir anlık görüntü eklenmiştir:
<configuration description="Runs Tests for Shell.">
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk" />
</target_preparer>
<option name="test-suite-tag" value="apct" />
<option name="test-tag" value="ShellTests" />
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="com.android.shell.tests" />
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
</test>
</configuration>
Test yapılandırma dosyasındaki bazı seçilmiş açıklamalar:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Bu, Ticaret Federasyonuna, belirtilen bir target_preparer kullanarak ShellTests.apk dosyasını hedef cihaza yüklemesini söyler. Ticaret Federasyonu'nda geliştiricilerin kullanabileceği çok sayıda hedef hazırlayıcı vardır ve bunlar, testin yürütülmesinden önce cihazın doğru şekilde kurulduğundan emin olmak için kullanılabilir.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="com.android.shell.tests"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Bu, testi yürütmek için kullanılacak Ticaret Federasyonu test sınıfını ve yürütülecek cihazdaki pakette geçenleri ve bu durumda JUnit olan test çalıştırıcı çerçevesini belirtir.
Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın
JUnit4 özellikleri
android-support-test
kütüphanesinin test çalıştırıcısı olarak kullanılması, yeni JUnit4 tarzı test sınıflarının benimsenmesine olanak tanır ve örnek gerrit değişikliği, özelliklerinin bazı çok temel kullanımını içerir.
Örnek gerrit değişikliğinin en son kaynak koduna şuradan erişilebilir: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java
Test kalıpları genellikle bileşen ekiplerine özel olsa da, genel olarak bazı faydalı kullanım kalıpları da vardır.
@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
JUnit4'teki önemli bir fark, testlerin artık ortak bir temel test sınıfından miras alınmasının gerekmemesidir; bunun yerine testleri düz Java sınıflarında yazarsınız ve belirli test kurulumunu ve kısıtlamalarını belirtmek için ek açıklamalar kullanırsınız. Bu örnekte bu sınıfın Android JUnit4 testi olarak çalıştırılması gerektiğini anlatıyoruz.
@SmallTest
ek açıklaması, test sınıfının tamamı için bir test boyutu belirledi: bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası sökme ve test sonrası sınıf sökme: JUnit4'teki setUp
ve tearDown
yöntemlerine benzer. Test
açıklaması, gerçek teste açıklama eklemek için kullanılır.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
@Before
ek açıklaması, ön test kurulumunu gerçekleştirmek için JUnit4 tarafından kullanılan yöntemlerde kullanılır. Bu örnekte kullanılmamasına rağmen, test sonrası sökme işlemi için @After
da bulunmaktadır. Benzer şekilde, @BeforeClass
ve @AfterClass
ek açıklamaları, bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve daha sonra sökmek için JUnit4 tarafından kullanılan yöntemlerde kullanılabilir. Sınıf kapsamı kurulumu ve sökme yöntemlerinin statik olması gerektiğini unutmayın.
Test yöntemlerine gelince, JUnit'in önceki sürümünden farklı olarak, artık yöntem adını test
ile başlatmaları gerekmiyor, bunun yerine her birinin @Test
ile açıklanması gerekiyor. Her zamanki gibi, test yöntemleri herkese açık olmalı, dönüş değeri bildirmemeli, parametre almamalı ve istisnalar atabilir.
Context context = InstrumentationRegistry.getTargetContext();
JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden, artık temel sınıf yöntemleri aracılığıyla getContext()
veya getTargetContext()
yoluyla Context
örneklerini elde etmek gerekli değildir; bunun yerine yeni test çalıştırıcısı bunları, enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry
aracılığıyla yönetir. Bu sınıf aracılığıyla şunları da arayabilirsiniz:
-
getInstrumentation()
:Instrumentation
sınıfının örneği -
getArguments()
:am instrument
-e <key> <value>
yoluyla aktarılan komut satırı argümanları
Yerel olarak derleyin ve test edin
En yaygın kullanım durumları için Atest'i kullanın.
Daha yoğun özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.