Otomatik enstrümantasyonlu testler örneği

Bir enstrümantasyon testi başlatıldığında, hedef paketi enstrümantasyon kodu eklenmiş ve yürütme için başlatılmış şekilde yeniden başlatılır. Bunun tek istisnası, buradaki hedef paketin Android uygulama çerçevesinin kendisi (ör. android paketi) olmamasıdır. Aksi takdirde, Android çerçevesinin yeniden başlatılması gerekir. Bu da enstrümantasyon da dahil olmak üzere sistem işlevlerini destekleyen şeydir.

Bu, araç testinin kendisini Android'e yerleştiremeyeceği anlamına gelir. çerçeve, yani sistem sunucusu, yani yürütme için kullanılır. Android'i test etmek için çerçevesini kullanıyorsanız, test kodu yalnızca herkese açık API yüzeylerini veya açık olan API yüzeylerini Android Arayüz Tanımlama Dili'ni kullanarak AIDL mevcuttur. Bu test kategorisi için belirli bir paketi hedeflemek anlamlı değildir. Bu nedenle, bu tür kendi test uygulama paketini hedeflemek üzere beyan edilecek enstrümanlar AndroidManifest.xml içeren kendi <manifest> etiketinde tanımlanmıştır.

Gereksinimlere bağlı olarak, bu kategorideki test uygulama paketleri ayrıca:

• Test için gerekli etkinlikleri gruplayın.
• Kullanıcı kimliğini sistemle paylaşın.
• Platform anahtarıyla imzalanmış olmalıdır.
• Herkese açık SDK yerine çerçeve kaynağına göre derlenmiş olmalıdır.

Bu araç testleri kategorisi bazen kendi kendine enstrümantasyonu kullanabilir. Aşağıda, Google Ads'deki kendi kendine araç testlerine ilişkin platform kaynağı:

• çerçeveler/temel/çekirdek/testler/
• frameworks/base/services/testler/hizmetlertestleri

Burada ele alınan örnek, hedef ile yeni bir araç testi yazmaktır. paketinin kendi test uygulama paketinde ayarlanır. Bu kılavuzda örnek olarak aşağıdaki test kullanılmıştır:

• Merhaba Dünya Enstrümantasyon Testi

Devam etmeden önce kabaca bir fikir edinmek için önce koda göz atmanız önerilir.

Kaynak konumu belirleyin

Genellikle ekibinizin kontrol etmesi gereken yerlerle ilgili belirli bir kalıbı vardır ve testlerin ekleneceği yerlerdir. Çoğu ekibin tek bir git deposu vardır veya bir deposu diğer ekiplerle paylaşır ancak bileşen kaynak kodunu içeren özel bir alt dizinleri vardır.

Bileşen kaynağınız için kök konumunun <component source root> konumunda olduğu varsayıldığında çoğu bileşenin altında src ve tests klasörleri, bazıları ise Android.mk gibi ek dosyalar (veya .mk ek dosyalara ayrılmış), manifest dosyası AndroidManifest.xml ve test yapılandırma dosyası "AndroidTest.xml".

Yepyeni bir test eklediğiniz için muhtemelen tests dizininizi src bulun ve içerikle doldurun.

Bazı durumlarda, farklı test paketlerinin tek tek apk'lara paketlenmesi gerektiğinden ekibinizin tests altında başka dizin yapıları olabilir. Ve Bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekir.

Yapı ne olursa olsun, sonunda tests dizini veya dizindekilere benzer dosyaları içeren yeni oluşturulan Örnek değer değişikliğindeki instrumentation dizini. Dosyaların ayrıntıları bu belgenin ilerleyen bölümlerinde açıklanmıştır.

Manifest dosyası

Uygulama projesinde olduğu gibi, her enstrümantasyon testi modülü için AndroidManifest.xml adlı bir manifest dosyası gerekir. Otomatik olarak eklemek için BUILD_PACKAGE temel oluşturma dosyasını kullanarak bu dosyayı, Test modülünüz için Android.mk dosyası.

AndroidManifest.xml dosyası hakkında bilginiz yoksa şuraya bakın: Uygulama manifestine genel bakış

Aşağıda örnek bir AndroidManifest.xml dosyası verilmiştir:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  android:sharedUserId="android.uid.system"
  package="android.test.example.helloworld" >

    <application>
       <uses-library android:name="android.test.runner"/>
    </application>

    <instrumentation android:name="androidx.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

Manifest dosyasıyla ilgili bazı önemli açıklamalar:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

package özelliği, uygulama paketi adıdır: Bu, benzersizdir Android uygulama çerçevesinin bir uygulamayı tanımlamak için kullandığı (veya bu bağlamda: test uygulamanız) ekleyebilirsiniz. Sistemdeki her bir kullanıcının bu paket adına sahip yalnızca bir uygulama yükleyebilir.

Ayrıca bu package özelliği, ComponentName#getPackageName() tarafından döndürülen değerle aynıdır ve adb shell kullanan çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullanacağınız değerle de aynıdır.

Paket adının genelde aynı stilde olmasına rağmen bir Java paketi adı olduğu için, aslında bu adla pek ilgisi yok. Başka uygulamanız (veya test) paketiniz herhangi bir paket içeren sınıflar içerebilir Ancak diğer yandan sadeliği tercih edebilir ve en iyi düzeyindeki Java paketi adı veya testin aynısı paket adı.

android:sharedUserId="android.uid.system"

Bu, yükleme sırasında bu APK dosyasına temel platformla aynı kullanıcı kimliğinin (ör. çalışma zamanı kimliği) verilmesi gerektiğini belirtir. Not: apk'nin temel platformla aynı sertifikayla imzalanmasına bağlıdır (önceki bölümde LOCAL_CERTIFICATE bölümüne bakın), ancak bu iki değer birbirinden farklıdır: kavramlar:

• bazı izinler veya API'ler imza korumalıdır. imzalayan sertifika
• bazı izinler veya API'ler, arayanın system kullanıcı kimliğini gerektirir. system ile paylaşması için çağrı paketi gerekir; temel platformun kendisinden ayrı bir paket

<uses-library android:name="android.test.runner" />

İlgili sınıflar şunlardır: ayrı bir çerçeve JAR kitaplık dosyasında paketlendiğinden test paketi uygulama çerçevesi tarafından çağrıldığında sınıf yolu girişleri.

android:targetPackage="android.test.example.helloworld"

Buradaki targetPackage öğesinin Bu dosyanın manifest etiketinde package özelliği belirtilmiş. Şurada belirtildiği gibi: test temelleri gibi, bu araç testi kategorisi genellikle çerçeve API'lerini test etmek amacıyla kullanılır. Dolayısıyla kendine ait olmayan belirli bir hedeflenen uygulama paketine sahip olmalarını sağlar.

Basit yapılandırma dosyası

Her yeni test modülünün yönlendirme yapması için bir yapılandırma dosyası olmalıdır. modül meta verileri, derleme süresi bağımlılıkları ve paketleme ile derleme sistemi bakın. Çoğu durumda Shortg tabanlı Blueprint dosya seçeneği yeterli olacaktır. Ayrıntılar için bkz. Basit Test Yapılandırması.

Karmaşık yapılandırma dosyası

Önemli: Bu bölümdeki talimatlar yalnızca CTS testleri veya Bluetooth'u devre dışı bırakma ya da veri toplama gibi özel kurulum gerektiren testler için gereklidir örnek verilerdir. Diğer tüm durumlar Basit Test Yapılandırması. Görüntüleyin Karmaşık Test Yapılandırması inceleyebilirsiniz.

Bu daha karmaşık durumlarda, Android'in test donanımı Trade Federation için bir test yapılandırması dosyası da yazmanız gerekir.

Test yapılandırması, özel cihaz kurulumu seçenekleri ve varsayılan ayarlar belirtebilir bağımsız değişkenlerin tümünü kullanırsınız. Örneği şurada görebilirsiniz: /platform_testing/tests/example/instrumentation/AndroidTest.xml olarak değiştirebilirsiniz.

Kolaylık sağlamak amacıyla buraya bir anlık görüntü eklenmiştir:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
  </test>
</configuration>

Test yapılandırma dosyasındaki bazı açıklamalar:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="HelloWorldTests.apk"/>
</target_preparer>

Bu, Ticaret Federasyonu'na HelloWorldTests.apk'yi hedefe yüklemesini söyler belirtilen bir target_preparer kullanarak cihaza yerleştirin. Hedef hazırlayan pek çok kişi vardır. Ticaret Federasyonu'ndaki geliştiriciler tarafından kullanılabiliyor ve bunlar, test yürütülmeden önce cihazın doğru şekilde kurulduğundan emin olun.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <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 geçer ve test çalıştırıcı, JUnit'i seçin.

Daha fazla bilgi için bkz. Modül Yapılandırmalarını Test Et.

JUnit4 özellikleri

android-support-test kitaplığının test çalıştırıcısı olarak kullanılması, JUnit4 stil testi sınıfları ve örnek değer değişikliği, olduğunu söylüyor. Örneği şurada görebilirsiniz: /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java.

Test kalıpları genellikle bileşen ekiplerine özgüdür ancak test sırasında yaygın olarak kullanılan kullanım kalıplarından bahsedeceğiz.

@RunWith(JUnit4.class)
public class HelloWorldTest {

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. İçinde bu örnekte, bu sınıfın bir JUnit4 testi olarak çalıştırılması gerektiği talimatını veriyoruz.

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

@Before ve @After ek açıklamaları, JUnit4 tarafından uygulanan yöntemlerde ve test sonrası desteğinin sonlandırılmasıyla ilgilidir. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, JUnit4 tarafından bir test sınıfındaki tüm testleri çalıştırmadan önce kurulum yapmak ve sonrasında da yıkım işlemini gerçekleştirmek için yöntemlerde kullanılır. Lütfen sınıf kapsamlı kurulum ve söküm yöntemleri statik olmalıdır. Test yöntemleri konusunda ise JUnit'in önceki sürümünün aksine, artık yöntem adının başlatılmasına gerek yoktur. test yerine, her birine @Test ile ek açıklama eklenmelidir. Her zamanki gibi test yöntemleri herkese açık olmalı, değer döndürmemeli, parametre almamalı ve istisnalar yapabilir.

Önemli: Test yöntemlerinin kendileri @Test ile belirtilir. notasyon; testlerin APCT ile yürütülebilmesi için test boyutları ile not verilmiş: örnek olarak testHelloWorld @SmallTest. Ek açıklama, yöntem kapsamında veya sınıf kapsamında uygulanabilir.

Enstrümantasyon sınıfına erişim

Temel Merhaba Dünya örneğinde ele alınmasa da bir Android testinin Instrumentation örneğine erişim gerektirmesi oldukça yaygındır: Bu, uygulama bağlamlarına, etkinlik yaşam döngüsü ile ilgili test API'lerine ve daha fazlasına erişim sağlayan temel API arayüzüdür.

JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden şunun üzerinden Instrumentation örneğini almak için gereklidir: InstrumentationTestCase#getInstrumentation() yerine yeni test kullanıcısı InstrumentationRegistry üzerinden yönetir enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulum saklanıyor.

Instrumentation sınıfı örneğine erişmek için statik yöntemi çağırmanız yeterlidir. InstrumentationRegistry sınıfta getInstrumentation():

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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 durumlarda araç talimatlarına bakın.