Kendi kendini kaydeden 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, bir enstrümantasyon testinin yürütülmek üzere kendisini Android çerçevesine (diğer adıyla sistem sunucusuna) ekleyemeyebileceği anlamına gelir. 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 enstrümantasyon testi kategorisine bazen kendi kendine enstrümantasyon da denir. Platform kaynağındaki kendi kendine enstrümantasyon testlerine ilişkin 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 konuma karar verme

Ekibiniz genellikle kodda kontrol edilecek ve test eklenecek yerlerle ilgili yerleşik bir düzene sahiptir. Ç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 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 tek tek apk'lara paketlemesi gerektiğinden ekibinizin tests altında başka dizin yapıları 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. 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. 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 Manifestine 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 Java paket adıyla ç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 ve aynı imzalama sertifikasını gerektirir
  • 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 hedef 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, 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ı

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ı, 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 için 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'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="android.test.example.helloworld"/>
  <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.

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 kapsamlı kurulum ve kaldırma 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.

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şmesi 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 statik getInstrumentation() yöntemini çağırmanız yeterlidir:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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.