Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedefleyenlerden çok da farklı değildir. Araçları içeren test başvurusunun, hedeflediği uygulama ile aynı sertifikayla imzalanması gerektiğini belirtmekte fayda var.
Bu kılavuzun, platform kaynak ağacı iş akışı hakkında bazı bilgilere sahip olduğunuzu varsaydığını unutmayın. Değilse, lütfen Gereksinimler bölümüne bakın. Burada ele alınan örnek, kendi test uygulama paketinde belirlenen hedef paketle yeni bir enstrümantasyon testi yazmaktır. Konsepte aşina değilseniz, lütfen Platform testi girişini baştan sona okuyun.
Bu kılavuz, örnek olarak hizmet etmek için aşağıdaki testi kullanır:
- çerçeveler/temel/paketler/Kabuk/testler
Devam etmeden önce kabaca bir izlenim edinmek için önce koda göz atmanız önerilir.
Bir kaynak konumuna karar verme
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 kendine enstrümantasyon testleri için uçtan uca örnekte kaynak konumu hakkında daha fazla tartışma görün.
Manifest dosyası
Tıpkı normal bir uygulama gibi, her enstrümantasyon test modülünün bir bildirim dosyasına ihtiyacı vardır. Dosyayı AndroidManifest.xml olarak adlandırır ve test tmodülünüz için Android.mk yanında sağlarsanız, BUILD_PACKAGE çekirdek makefile tarafından otomatik olarak eklenir.
Daha fazla ilerlemeden önce, Uygulama Manifestosu Genel Bakışını incelemeniz önemle tavsiye edilir.
Bu, bir bildirim dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sağlar.
Örnek gerrit değişikliği için 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>
Manifest 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 paketi 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ı, bu paket adıyla yalnızca bir uygulama yükleyebilir.
Bu, test edilen uygulama paketinden bağımsız bir test uygulama paketi olduğundan, farklı bir paket adı kullanılmalıdır: yaygın bir kural, .test son ekini eklemektir.
Ayrıca, bu package özniteliği ComponentName#getPackageName() öğesinin döndürdüğü öznitelik ile aynıdır ve ayrıca adb shell aracılığıyla çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullandığınızla aynıdır.
Lütfen ayrıca, paket adının tipik olarak bir Java paket adıyla aynı stilde olmasına rağmen, aslında bununla çok az ilgisi olduğunu 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 bulundurabilir veya uygulama paket adıyla aynı test edebilirsiniz.
<uses-library android:name="android.test.runner" />
İlgili sınıflar ayrı bir çerçeve jar kitaplığı dosyasında paketlendiğinden, bu nedenle test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerektirdiğinden, bu tüm Enstrümantasyon testleri için gereklidir.
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 test yürütme işlemi için enstrümantasyon kodunu sürece enjekte eder. Bu ayrıca, test kodunun, test edilen uygulamada çalışan tüm sınıf örneklerine erişebileceği ve maruz kalan test kancalarına bağlı olarak durumu değiştirebileceği anlamına gelir.
Basit yapılandırma dosyası
Her yeni test modülünün, yapı sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme yönergeleri ile yönlendirmek için bir yapılandırma dosyası olmalıdır. Çoğu durumda, Soong tabanlı Blueprint dosya 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 ayrıca Android'in test donanımı Trade Federation için bir test yapılandırma dosyası 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ği için yapılandırma dosyasının en son sürümüne şu adresten 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 konfigürasyon 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 Federasyonu'na ShellTests.apk dosyasını belirtilen bir target_preparer kullanarak hedef cihaza yüklemesini söyler. Trade Federation'da geliştiricilerin kullanabileceği pek çok hedef hazırlayıcı vardır ve bunlar, test yürütmeden ö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ı belirtir ve yürütülecek cihazdaki pakete ve bu durumda JUnit olan test çalıştırma çerçevesine geçer.
Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın
JUnit4 özellikleri
android-support-test kitaplığının test yürütücüsü olarak kullanılması, yeni JUnit4 tarzı test sınıflarının benimsenmesini sağlar ve örnek gerrit değişikliği, özelliklerinin bazı çok temel kullanımlarını içerir.
Örnek gerrit değişikliği için en son kaynak koduna şu adresten erişilebilir: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java
Test kalıpları genellikle bileşen ekiplerine özgü olsa da, genel olarak yararlı bazı kullanım kalıpları 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ı 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çıklama kullanırsınız. Bu örnekte, bu sınıfın bir Android JUnit4 testi olarak çalıştırılması talimatını veriyoruz.
@SmallTest ek açıklaması, tüm test sınıfı için bir test boyutu belirledi: bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu ek açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası ayırma ve test sonrası sınıf ayırma: 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 yöntemlerde kullanılır. Bu örnekte kullanılmasa da, test sonrası sökme işlemi için @After da vardır. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, JUnit4 tarafından bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve ardından sökmek için yöntemlerde kullanılabilir. Sınıf kapsamı kurulumu ve ayırma 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ı gerekmez, bunun yerine her birinin @Test ile açıklanması gerekir. Her zaman olduğu gibi, test yöntemleri genel 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, temel sınıf yöntemleri aracılığıyla getContext() veya getTargetContext() yoluyla Context örnekleri elde etmek artık 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():Instrumentationsınıfının örneği -
getArguments():am instrument-e <key> <value>yoluyla iletilen komut satırı bağımsız değişkenleri
Yerel olarak oluşturun ve test edin
En yaygın kullanım durumları için Atest kullanın.
Daha fazla özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.