Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedefleyen testlerden ç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 Şartlar bölümüne bakın. Burada ele alınan örnekte, hedef paket kendi test uygulama paketinde ayarlanmış yeni bir enstrümantasyon testi yazılmaktadır. Bu kavrama aşina değilseniz lütfen Platform testi girişi 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 önce koda göz atmanız önerilir.
Kaynak konuma karar verme
Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, test kaynak kodunun platform kaynak ağacındaki bileşen kaynak dizininizin kök dizininin altındaki bir tests dizine yerleştirilmesi önerilir.
Kaynak konum hakkında daha fazla bilgiyi kendi kendini ölçen testler için uçtan uca örnek bölümünde bulabilirsiniz.
Manifest dosyası
Normal bir uygulamada olduğu gibi, her enstrümantasyon testi modülü için bir manifest dosyası gerekir. Dosyayı AndroidManifest.xml olarak adlandırır ve test modülünüzün yanında Android.mk olarak sağlarsanız BUILD_PACKAGE çekirdek makefile'i tarafından otomatik olarak eklenir.
Devam etmeden önce Uygulama Manifesti'ne Genel Bakış bölümünü incelemeniz önemle tavsiye edilir.
Bu sayfada, manifest dosyasının temel bileşenlerine ve işlevlerine genel bir bakış sunulmaktadır.
Örnek gerrit değişikliğine ait manifest 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 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ıyla ilgili bazı önemli açıklamalar:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
package özelliği, uygulama paket adıdır: 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.
Test edilen uygulama paketinden bağımsız bir test uygulaması paketi olduğundan farklı bir paket adı kullanılmalıdır. Yaygın bir uygulama, .test son eki eklemektir.
Ayrıca bu package özelliği, ComponentName#getPackageName() tarafından döndürülen değerle aynıdır ve adb shell aracılığıyla çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullanacağınız değerle de aynıdır.
Paket adının genellikle Java paket adıyla aynı tarzda olmasına rağmen aslında bu ikisinin çok az ortak noktası olduğunu da unutmayın. Diğer 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 uygulamanızdaki veya testinizdeki üst düzey Java paket adını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 ve 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.
Araçlar 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şlemine araç kodunu ekler. Bu, test kodunun test edilen uygulamada çalışan tüm sınıf örneklerine erişebileceği ve 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 verileriyle, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek 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 donanımı Trade Federation için bir test yapılandırma dosyası da yazmanız gerekir.
Test yapılandırması, test sınıfını sağlamak için özel cihaz kurulumu seçenekleri ve varsayılan bağımsız değişkenler belirtebilir.
Ö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 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ırması dosyasıyla ilgili bazı önemli açıklamalar:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Bu, Trade Federation'a ShellTests.apk'yı belirtilen bir target_preparer kullanarak hedef cihaza yüklemesini söyler. Trade Federation'da geliştiricilerin kullanabileceği birçok hedef hazırlayıcı vardır. Bu hazırlayıcılar, testin yürütülmesinden önce cihazın düzgün şekilde ayarlanması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 Trade Federation test sınıfını belirtir ve yürütülecek cihazdaki paketi ve test çalıştırıcı çerçevesini (bu durumda JUnit) iletir.
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ın kullanılması, 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 genellikle yararlı olan 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 yazar ve belirli test kurulumlarını ve kısıtlamalarını belirtmek için ek açıklama kullanırsınız. Bu örnekte, bu sınıfın Android JUnit4 testi olarak çalıştırılması gerektiğini belirtiyoruz.
@SmallTest ek açıklama, test sınıfının tamamı için bir test boyutu belirtmiştir: Bu test sınıfına eklenen tüm test yöntemleri bu test boyutu ek açıklamasını devralır. sınıf testi öncesi kurulum, test sonrası yıkım ve test sonrası sınıf yıkımı: JUnit4'teki setUp ve tearDown yöntemlerine benzer.
Test ek açıklama, gerçek testi ek 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ı teardown için @After de 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 kurulum yapmak ve sonrasında da yıkım işlemi yapmak için 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'ın önceki sürümlerinden farklı olarak artık yöntem adının test ile başlaması gerekmiyor. Bunun yerine, her biri @Test ile ek açıklamaya tabi tutulmalıdır. Her zamanki gibi, test yöntemleri herkese açık olmalı, döndürülen değer belirtmemeli, parametre almamalı ve istisna atabilir.
Context context = InstrumentationRegistry.getTargetContext();
JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden, Context örneklerini getContext() aracılığıyla veya getTargetContext() temel sınıf yöntemleri aracılığıyla elde etmek gerekmez. Bunun yerine, yeni test çalıştırıcı bunları InstrumentationRegistry aracılığıyla yönetir. Bu sınıfta, enstrümasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulum depolanır. Bu sınıf aracılığıyla şunları da çağırabilirsiniz:
getInstrumentation():Instrumentationsınıfının örneğigetArguments():-e <key> <value>aracılığıylaam instrument'a iletilen komut satırı bağımsız değişkenleri
Yerel olarak derleme ve test etme
En yaygın kullanım alanları için Atest'i kullanın.
Daha fazla özelleştirme gerektiren daha karmaşık durumlar için araçlarla ilgili talimatları uygulayın.