Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedefleyenlerden çok farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulamayla aynı sertifikayla imzalanması gerektiğini unutmayın.
Bu kılavuzda, platform kaynak ağacı iş akışı hakkında bilgi sahibi olduğunuz varsayılmaktadır. Aksi takdirde lütfen Koşullar bölümüne bakın. Burada ele alınan örnek, hedef paketin kendi test uygulaması paketine ayarlandığı yeni bir enstrümantasyon testi yazmaktır. Bu kavram hakkında bilginiz yoksa lütfen Platform testiyle ilgili giriş başlıklı makaleyi okuyun.
Bu kılavuzda örnek olarak aşağıdaki test kullanılmaktadır:
- frameworks/base/packages/Shell/tests
Devam etmeden önce kabaca bir fikir edinmek için kodu incelemeniz önerilir.
Kaynak konumuna karar verme
Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, test kaynak kodunu platform kaynak ağacındaki bileşen kaynak dizininizin kökü altında bulunan bir tests dizinine yerleştirmek geleneksel bir yöntemdir.
Kaynak konumuyla ilgili daha fazla tartışma için kendi kendine enstrümanlı testlerle ilgili uçtan uca örneğe bakın.
Manifest dosyası
Her enstrümantasyon testi modülünün, normal bir uygulamada olduğu gibi bir manifest dosyası olması gerekir. Dosyayı AndroidManifest.xml olarak adlandırıp test modülünüz için Android.mk yanında sağlarsanız BUILD_PACKAGE temel makefile'ı tarafından otomatik olarak dahil edilir.
Devam etmeden önce Uygulama Manifestine Genel Bakış'ı incelemeniz önemle tavsiye edilir.
Bu bölümde, manifest dosyasının temel bileşenleri ve işlevleri hakkında genel bilgiler verilmektedir.
Örnek gerrit değişikliğinin manifest dosyasının en son sürümüne şu adresten erişilebilir: https://android.googlesource.com/platform/frameworks/base/+/android16-release/packages/Shell/tests/AndroidManifest.xml
Kolaylık sağlamak için buraya bir ekran görüntüsü 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ıyla ilgili bazı önemli noktalar:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
package özelliğ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ı, bu paket adına sahip 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 olarak .test soneki eklenir.
Ayrıca bu package özelliği, ComponentName#getPackageName() tarafından döndürülenle aynıdır ve adb shell üzerinden çeşitli pm alt komutlarıyla etkileşim kurmak için kullanacağınızla da aynıdır.
Paket adının genellikle bir Java paket adıyla aynı stilde olmasına rağmen aslında bununla çok az ilgisi olduğunu da lütfen unutmayın. Diğer bir deyişle, uygulama (veya test) paketiniz herhangi bir paket adıyla sınıflar içerebilir. Ancak basitliği tercih edebilir ve uygulamanızda veya testinizde üst düzey Java paket adınızın uygulama paket adıyla aynı olmasını sağlayabilirsiniz.
<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. Bu nedenle, test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerekir.
android:targetPackage="com.android.shell"
Bu, enstrümantasyonun hedef paketini com.android.shell olarak ayarlar.
Araç am instrument komutuyla çağrıldığında çerçeve, com.android.shell işlemini yeniden başlatır ve test yürütme için işleme araç kodu ekler. Bu, test kodunun, test edilen uygulamada çalışan tüm sınıf örneklerine erişebileceği ve gösterilen 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ünde, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirmek için bir yapılandırma dosyası bulunmalıdır. Çoğu durumda, Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması başlıklı makaleyi inceleyin.
Karmaşık yapılandırma dosyası
Daha karmaşık testler için Android'in test koşum takımı Trade Federation için bir test yapılandırma dosyası da yazmanız gerekir.
Test yapılandırmasında, test sınıfına sağlanacak özel cihaz kurulumu seçenekleri ve varsayılan bağımsız değişkenler belirtilebilir.
Örnek Gerrit değişikliğinin 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 ekran görüntüsü 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ıyla ilgili bazı önemli noktalar:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Bu komut, Ticaret Federasyonu'na ShellTests.apk'yı belirtilen bir target_preparer kullanarak hedef cihaza yüklemesini söyler. Ticaret Federasyonu'nda geliştiricilerin kullanımına sunulan birçok hedef hazırlayıcı vardır. Bunlar, test yürütülmeden önce cihazın düzgün şekilde kurulmasını sağlamak 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 paketi cihazda ve test çalıştırıcı çerçevesini (bu durumda JUnit) geçirir.
Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın.
JUnit4 özellikleri
Test çalıştırıcı olarak android-support-test kitaplığını kullanmak, yeni JUnit4 tarzı test sınıflarının benimsenmesini sağlar. Örnek Gerrit değişikliği, özelliklerinin çok temel bir kullanımını içerir.
Örnek Gerrit değişikliğinin 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 faydalı 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 devralınmasının gerekmemesidir. Bunun yerine, testleri düz Java sınıflarında yazıp belirli test kurulumunu ve kısıtlamaları belirtmek için ek açıklamayı kullanırsınız. Bu örnekte, bu sınıfın Android JUnit4 testi olarak çalıştırılması talimatı veriliyor.
@SmallTest ek açıklaması, test sınıfının tamamı için bir test boyutu belirtir: Bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu ek açıklamasını devralır.
Test sınıfı kurulumu öncesi, test sonrası yıkım ve test sınıfı sonrası yıkım:
JUnit4'teki setUp ve tearDown yöntemlerine benzer.
Test ek açıklaması, gerçek testi açıklamak için kullanılır.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
@Before ek açıklaması, JUnit4 tarafından test öncesi kurulumu gerçekleştirmek için yöntemlerde kullanılır.
Bu örnekte kullanılmasa da test sonrası analiz için @After de vardır.
Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, bir test sınıfındaki tüm testler yürütülmeden önce kurulum yapmak ve sonrasında yıkım yapmak için JUnit4 tarafından yöntemlerde kullanılabilir. Sınıf kapsamlı kurulum ve yıkım yöntemlerinin statik olması gerektiğini unutmayın.
Test yöntemlerine gelince, JUnit'in önceki sürümlerinin aksine, artık yöntem adının test ile başlaması gerekmiyor. Bunun yerine, her birine @Test eklenmelidir. Her zamanki gibi, test yöntemleri herkese açık olmalı, dönüş değeri bildirmemeli, parametre almamalı ve istisnalar oluşturabilir.
Context context = InstrumentationRegistry.getTargetContext();
JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden Context örneklerinin getContext() veya getTargetContext() aracılığıyla temel sınıf yöntemleriyle alınması gerekmez. Bunun yerine, yeni test çalıştırıcı bunları InstrumentationRegistry aracılığıyla yönetir. Burada, enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulum saklanır. Bu sınıf aracılığıyla şunları da arayabilirsiniz:
getInstrumentation():Instrumentationsınıfının örneğigetArguments():am instrument'ye-e <key> <value>üzerinden iletilen komut satırı bağımsız değişkenleri-e <key> <value>
Yerel olarak derleme ve test etme
En yaygın kullanım alanlarında Atest'i kullanın.
Daha fazla özelleştirme gerektiren daha karmaşık durumlarda enstrüman talimatlarını uygulayın.