Otomatik enstrümantasyonlu testler örneği

Bir araç testi başlatıldığında hedef paketi, enstrümantasyon kodu yerleştirilerek yeniden başlatılır ve yürütülmek üzere 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.

Diğer bir deyişle, bir araç testi, yürütme için kendisini Android çerçevesine (yani sistem sunucusu olarak da bilinir) yerleştiremez. Android çerçevesini test etmek için test kodu yalnızca herkese açık API yüzeylerini veya platform kaynak ağacında bulunan Android Arayüz Tanımlama Dili AIDL kullanılarak sunulan yüzeyleri çağırabilir. Bu test kategorisinde belirli bir paketi hedeflemek anlamlı değildir. Bu nedenle, bu tür enstrümanların kendi AndroidManifest.xml <manifest> etiketinde tanımlandığı şekilde kendi test uygulama paketini hedeflediği beyan edilir.

Gereksinimlere bağlı olarak, bu kategorideki test uygulama paketleri şunları da yapabilir:

  • Test için gereken paket etkinlikleri.
  • 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, kendi kendine enstrümantasyon olarak da adlandırılır. Platform kaynağındaki kendi kendine enstrümantasyon testlerine dair bazı örnekler aşağıda verilmiştir:

Burada ele alınan örnekte, hedef paket kendi test uygulaması paketinde ayarlanmış yeni bir enstrümantasyon testi yazılmaktadır. Bu kılavuzda örnek olarak aşağıdaki test kullanılmaktadır:

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

Kaynak konumu belirleyin

Ekibiniz genellikle kodda kontrol edilecek ve test eklenecek yerlerle ilgili yerleşik bir düzene sahiptir. Çoğu ekip, tek bir Git deposuna sahiptir veya bir depoyu diğer ekiplerle paylaşıp bileşen kaynak kodunu içeren özel bir alt dizine sahiptir.

Bileşen kaynağınızın kök konumunun <component source root> olduğunu varsayarsak çoğu bileşenin altında src ve tests klasörleri ve Android.mk gibi bazı ek dosyalar (veya ek .mk dosyalarına bölünmüş), manifest dosyası AndroidManifest.xml ve test yapılandırma dosyası 'AndroidTest.xml' bulunur.

Yepyeni bir test eklediğiniz için muhtemelen src bileşeninizin yanında tests dizinini oluşturmanız ve içeriği doldurmanız gerekir.

Bazı durumlarda, farklı test paketlerini ayrı apk'ler halinde paketleme ihtiyacı nedeniyle ekibiniz tests altında başka dizin yapılarına sahip olabilir. Bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekir.

Yapıdan bağımsız olarak, tests dizinini veya yeni oluşturulan alt dizini, örnek gerrit değişikliğindeki instrumentation dizininde bulunanlara benzer dosyalarla doldurursunuz. Her bir dosyayla ilgili 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. BUILD_PACKAGE çekirdek makefile'ini kullanarak bu dosyayı otomatik olarak dahil etmek için test modülünüzün Android.mk dosyasının yanında bu dosyayı sağlayın.

AndroidManifest.xml dosyasını bilmiyorsanız Uygulama Manifesti'ne Genel Bakış başlıklı makaleyi inceleyin.

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 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.

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ı genellikle Java paket adıyla aynı tarzda olsa da aslında bu ikisinin çok az ortak noktası olduğunu 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.

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. Bunun, APK'nın temel platformla aynı sertifikayla imzalanmasına bağlı olduğunu (önceki bölümdeki LOCAL_CERTIFICATE bölümüne bakın) ancak bunların farklı kavramlar olduğunu unutmayın:

  • Bazı izinler veya API'ler imza korumalıdır. Bu durumda aynı imzalama sertifikası gerekir.
  • Bazı izinler veya API'ler, arayan kullanıcının system kullanıcı kimliğini gerektirir. Bu da, arayan paketin, ana platformdan ayrı bir paketse kullanıcı kimliğini system ile paylaşmasını gerektirir.
<uses-library android:name="android.test.runner" />

İlgili sınıflar ayrı bir çerçeve JAR kitaplık 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="android.test.example.helloworld"

Buradaki targetPackage özelliğinin, bu dosyanın manifest etiketinde tanımlanan package özelliğiyle aynı şekilde tanımlandığını fark etmiş olabilirsiniz. Testin temelleri bölümünde belirtildiği gibi, bu enstrümantasyon testi kategorisi genellikle çerçeve API'lerini test etmek için tasarlanmıştır. Bu nedenle, kendileri dışında belirli bir hedeflenmiş uygulama paketine sahip olmaları pek anlamlı değildir.

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 Shortg tabanlı Blueprint dosya 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 olan bu tür durumlarda, Android'in test cihazı Ticaret Federasyonu 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. /platform_testing/tests/example/instrumentation/AndroidTest.xml adresindeki örneğe bakın.

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ırması dosyasıyla ilgili bazı önemli açıklamalar:

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

Bu, Trade Federation'a HelloWorldTests.apk'yi 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="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ı ve yürütülecek cihazdaki paketi geçer ve test çalıştırıcı çerçevesi (bu örnekte JUnit) belirtir.

Daha fazla bilgi için Test modülü yapılandırmaları başlıklı makaleyi inceleyin.

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. /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java adresindeki örneği inceleyin.

Test kalıpları genellikle bileşen ekiplerine özgü olsa da genellikle yararlı olan bazı kullanım kalıpları vardır.

@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. Bu örnekte, bu sınıfın JUnit4 testi olarak çalıştırılması gerektiğini belirtiyoruz.

    @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 test öncesi kurulum ve test sonrası yıkım gerçekleştirmek için yöntemlerde kullanılır. 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. Sınıf kapsamı kurulum ve sökme yöntemlerinin statik olması gerektiğini unutmayın. Test yöntemlerine gelince, JUnit'in önceki sürümünün aksine, artık yöntem adının test ile başlaması gerekmez. Bunun yerine, her birine @Test ile açıklama eklenmesi gerekir. Her zamanki gibi, test yöntemleri herkese açık olmalı, döndürülen değer belirtmemeli, parametre almamalı ve istisna atabilir.

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 Instrumentation örneğini InstrumentationTestCase#getInstrumentation() aracılığıyla elde etmek gerekmez. Bunun yerine yeni test çalıştırıcı, enstrümasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry aracılığıyla bu işlemi yönetir.

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

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

Yerel olarak derleyin ve test edin

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.