Bu araç 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. Değilse lütfen Şartlar'a 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
Araç 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 kullanan testler için uçtan uca örnekte kaynak konumuyla ilgili diğer tartışmaları inceleyebilirsiniz.
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 ilk olarak Uygulama Manifest'e Genel Bakış'ı incelemeniz önemle tavsiye edilir.
Burada, bir manifest dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sunulur.
Ö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 amacıyla 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ı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 işlem, 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 sürecine araç kodu 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ünün, derleme sistemini modül meta verileri, derleme süresi bağımlılıkları ve paketleme talimatlarıyla birlikte yönlendirmek için bir yapılandırma dosyası olmalıdır. Çoğu durumda, Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması bölümüne bakın.
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. Ticaret Federasyonu'nda geliştiricilerin kullanabileceği çok sayıda hedef hazırlayıcı vardır. Bunlar, test yürütülmeden önce cihazın doğru ş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 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ı mevcuttur.
@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ı halinde yazar ve belirli test kurulumunu ve kısıtlamaları 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 oluşturma, 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ı, test öncesi kurulumu gerçekleştirmek için JUnit4 tarafından kullanılan 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 arayabilirsiniz:
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 ağır özelleştirme gerektiren daha karmaşık durumlar için araç talimatlarını uygulayın.