Bir uygulama örneğini hedefleyin

Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedef alan testlerden çok da farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulamayla aynı sertifikayla imzalanması gerektiğini belirtmekte fayda var.

Bu kılavuzun, platform kaynak ağacı iş akışı hakkında zaten bir miktar bilgiye sahip olduğunuzu varsaydığını unutmayın. Değilse lütfen Gereksinimler'e bakın. Burada ele alınan örnek, kendi test uygulama paketinde belirlenen hedef paketle yeni bir enstrümantasyon testi yazmaktır. Konsepte yabancıysanız lütfen Platform testi girişini okuyun.

Bu kılavuz örnek olarak aşağıdaki testi kullanır:

  • çerçeveler/temel/paketler/Kabuk/testler

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

Kaynak konumuna karar verin

Enstrümantasyon 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 kendini test eden testlere yönelik uçtan uca örnekte kaynak konumu hakkında daha fazla tartışmaya bakın.

Bildirim dosyası

Normal bir uygulamada olduğu gibi, her enstrümantasyon test modülünün bir bildirim dosyasına ihtiyacı vardır. Dosyayı AndroidManifest.xml olarak adlandırırsanız ve test modülünüz için Android.mk yanında sağlarsanız, BUILD_PACKAGE çekirdek makefile tarafından otomatik olarak dahil edilecektir.

Daha fazla ilerlemeden önce Uygulama Bildirimine Genel Bakış'ı incelemeniz önemle tavsiye edilir.

Bu, bir bildirim dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sunar.

Örnek gerrit değişikliğine ilişkin bildirim 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 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>

Bildiri dosyasındaki bazı seçilmiş açıklamalar:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package niteliği, uygulama paketinin adıdır: Bu, 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ı o paket adı ile yalnızca bir uygulama kurabilir.

Bu bir test uygulama paketi olduğundan, test edilen uygulama paketinden bağımsız olarak farklı bir paket adı kullanılmalıdır: yaygın bir kural, .test son ekinin eklenmesidir.

Ayrıca, bu package niteliği ComponentName#getPackageName() işlevinin döndürdüğü öznitelikle aynıdır ve ayrıca adb shell aracılığıyla çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullanacağınız öznitelikle aynıdır.

Ayrıca paket adının genellikle Java paket adıyla aynı tarzda olmasına rağmen aslında onunla çok az ilgisi olduğunu lütfen unutmayın. Başka 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 üst düzey Java paket adınızı uygulamanızda veya testinizde uygulama paket adıyla aynı tutabilirsiniz.

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

İlgili sınıflar ayrı bir çerçeve jar kitaplığı dosyasında paketlendiğinden bu, tüm Enstrümantasyon testleri için gereklidir, dolayısıyla test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerektirir.

android:targetPackage="com.android.shell"

Bu, enstrümantasyonun hedef paketini com.android.shell olarak ayarlar. Enstrümantasyon am instrument komutu aracılığıyla çağrıldığında, çerçeve com.android.shell işlemini yeniden başlatır ve testin yürütülmesi için enstrümantasyon kodunu sürece enjekte eder. Bu aynı zamanda test kodunun, test altındaki uygulamada çalışan tüm sınıf örneklerine erişebileceği ve açığa çıkan 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ü, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyasına sahip olmalıdır. Çoğu durumda Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması'na bakın.

Karmaşık yapılandırma dosyası

Daha karmaşık testler için, Android'in test koşum takımı Trade Federasyonu için bir test yapılandırma dosyası da yazmanız gerekir.

Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.

Örnek gerrit değişikliğine ilişkin yapılandırma dosyasının en son sürümüne şuradan erişilebilir: frameworks/base/packages/Shell/tests/AndroidTest.xml

Kolaylık sağlamak için buraya 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ırma dosyasındaki bazı seçilmiş açıklamalar:

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

Bu, Ticaret Federasyonuna, belirtilen bir target_preparer kullanarak ShellTests.apk dosyasını hedef cihaza yüklemesini söyler. Ticaret Federasyonu'nda geliştiricilerin kullanabileceği çok sayıda hedef hazırlayıcı vardır ve bunlar, testin yürütülmesinden önce cihazın doğru şekilde kurulduğundan emin olmak 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 Ticaret Federasyonu test sınıfını ve yürütülecek cihazdaki pakette geçenleri ve bu durumda JUnit olan test çalıştırıcı çerçevesini belirtir.

Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın

JUnit4 özellikleri

android-support-test kütüphanesinin test çalıştırıcısı olarak kullanılması, yeni JUnit4 tarzı test sınıflarının benimsenmesine olanak tanır ve örnek gerrit değişikliği, özelliklerinin bazı çok temel kullanımını içerir.

Örnek gerrit değişikliğinin en son kaynak koduna şuradan erişilebilir: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Test kalıpları genellikle bileşen ekiplerine özel olsa da, genel olarak bazı faydalı kullanım kalıpları da 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 miras alınmasının gerekmemesidir; bunun yerine testleri düz Java sınıflarında yazarsınız ve belirli test kurulumunu ve kısıtlamalarını belirtmek için ek açıklamalar kullanırsınız. Bu örnekte bu sınıfın Android JUnit4 testi olarak çalıştırılması gerektiğini anlatıyoruz.

@SmallTest ek açıklaması, test sınıfının tamamı için bir test boyutu belirledi: bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası sökme ve test sonrası sınıf sökme: JUnit4'teki setUp ve tearDown yöntemlerine benzer. Test açıklaması, gerçek teste açıklama eklemek için kullanılır.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

@Before ek açıklaması, ön test kurulumunu gerçekleştirmek için JUnit4 tarafından kullanılan yöntemlerde kullanılır. Bu örnekte kullanılmamasına rağmen, test sonrası sökme işlemi için @After da bulunmaktadır. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve daha sonra sökmek için JUnit4 tarafından kullanılan yöntemlerde kullanılabilir. Sınıf kapsamı kurulumu ve sökme yöntemlerinin statik olması gerektiğini unutmayın.

Test yöntemlerine gelince, JUnit'in önceki sürümünden farklı olarak, artık yöntem adını test ile başlatmaları gerekmiyor, bunun yerine her birinin @Test ile açıklanması gerekiyor. Her zamanki gibi, test yöntemleri herkese açık olmalı, dönüş değeri bildirmemeli, parametre almamalı ve istisnalar atabilir.

        Context context = InstrumentationRegistry.getTargetContext();

JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden, artık temel sınıf yöntemleri aracılığıyla getContext() veya getTargetContext() yoluyla Context örneklerini elde etmek gerekli değildir; bunun yerine yeni test çalıştırıcısı bunları, enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry aracılığıyla yönetir. Bu sınıf aracılığıyla şunları da arayabilirsiniz:

  • getInstrumentation() : Instrumentation sınıfının örneği
  • getArguments() : am instrument -e <key> <value> aracılığıyla aktarılan komut satırı argümanları

Yerel olarak derleyin ve test edin

En yaygın kullanım durumları için Atest'i kullanın.

Daha yoğun özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.

,

Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedef alan testlerden çok da farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulamayla aynı sertifikayla imzalanması gerektiğini belirtmekte fayda var.

Bu kılavuzun, platform kaynak ağacı iş akışı hakkında zaten bir miktar bilgiye sahip olduğunuzu varsaydığını unutmayın. Değilse lütfen Gereksinimler'e bakın. Burada ele alınan örnek, kendi test uygulama paketinde belirlenen hedef paketle yeni bir enstrümantasyon testi yazmaktır. Konsepte yabancıysanız lütfen Platform testi girişini okuyun.

Bu kılavuz örnek olarak aşağıdaki testi kullanır:

  • çerçeveler/temel/paketler/Kabuk/testler

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

Kaynak konumuna karar verin

Enstrümantasyon 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 kendini test eden testlere yönelik uçtan uca örnekte kaynak konumu hakkında daha fazla tartışmaya bakın.

Bildirim dosyası

Normal bir uygulamada olduğu gibi, her enstrümantasyon test modülünün bir bildirim dosyasına ihtiyacı vardır. Dosyayı AndroidManifest.xml olarak adlandırırsanız ve test modülünüz için Android.mk yanında sağlarsanız, BUILD_PACKAGE çekirdek makefile tarafından otomatik olarak dahil edilecektir.

Daha fazla ilerlemeden önce Uygulama Bildirimine Genel Bakış'ı incelemeniz önemle tavsiye edilir.

Bu, bir bildirim dosyasının temel bileşenlerine ve bunların işlevlerine genel bir bakış sunar.

Örnek gerrit değişikliğine ilişkin bildirim 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 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>

Bildiri dosyasındaki bazı seçilmiş açıklamalar:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package niteliği, uygulama paketinin adıdır: Bu, 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ı o paket adı ile yalnızca bir uygulama kurabilir.

Bu bir test uygulama paketi olduğundan, test edilen uygulama paketinden bağımsız olarak farklı bir paket adı kullanılmalıdır: yaygın bir kural, .test son ekinin eklenmesidir.

Ayrıca, bu package niteliği ComponentName#getPackageName() işlevinin döndürdüğü öznitelikle aynıdır ve ayrıca adb shell aracılığıyla çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullanacağınız öznitelikle aynıdır.

Ayrıca paket adının genellikle Java paket adıyla aynı tarzda olmasına rağmen aslında onunla çok az ilgisi olduğunu lütfen unutmayın. Başka 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 üst düzey Java paket adınızı uygulamanızda veya testinizde uygulama paket adıyla aynı tutabilirsiniz.

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

İlgili sınıflar ayrı bir çerçeve jar kitaplığı dosyasında paketlendiğinden bu, tüm Enstrümantasyon testleri için gereklidir, dolayısıyla test paketi uygulama çerçevesi tarafından çağrıldığında ek sınıf yolu girişleri gerektirir.

android:targetPackage="com.android.shell"

Bu, enstrümantasyonun hedef paketini com.android.shell olarak ayarlar. Enstrümantasyon am instrument komutu aracılığıyla çağrıldığında, çerçeve com.android.shell işlemini yeniden başlatır ve testin yürütülmesi için enstrümantasyon kodunu sürece enjekte eder. Bu aynı zamanda test kodunun, test altındaki uygulamada çalışan tüm sınıf örneklerine erişebileceği ve açığa çıkan 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ü, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyasına sahip olmalıdır. Çoğu durumda Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması'na bakın.

Karmaşık yapılandırma dosyası

Daha karmaşık testler için, Android'in test koşum takımı Trade Federasyonu için bir test yapılandırma dosyası da yazmanız gerekir.

Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.

Örnek gerrit değişikliğine ilişkin yapılandırma dosyasının en son sürümüne şuradan erişilebilir: frameworks/base/packages/Shell/tests/AndroidTest.xml

Kolaylık sağlamak için buraya 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ırma dosyasındaki bazı seçilmiş açıklamalar:

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

Bu, Ticaret Federasyonuna, belirtilen bir target_preparer kullanarak ShellTests.apk dosyasını hedef cihaza yüklemesini söyler. Ticaret Federasyonu'nda geliştiricilerin kullanabileceği çok sayıda hedef hazırlayıcı vardır ve bunlar, testin yürütülmesinden önce cihazın doğru şekilde kurulduğundan emin olmak 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 Ticaret Federasyonu test sınıfını ve yürütülecek cihazdaki pakette geçenleri ve bu durumda JUnit olan test çalıştırıcı çerçevesini belirtir.

Test Modülü Yapılandırmaları hakkında daha fazla bilgi için buraya bakın

JUnit4 özellikleri

android-support-test kütüphanesinin test çalıştırıcısı olarak kullanılması, yeni JUnit4 tarzı test sınıflarının benimsenmesine olanak tanır ve örnek gerrit değişikliği, özelliklerinin bazı çok temel kullanımını içerir.

Örnek gerrit değişikliğinin en son kaynak koduna şuradan erişilebilir: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Test kalıpları genellikle bileşen ekiplerine özel olsa da, genel olarak bazı faydalı kullanım kalıpları da 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 miras alınmasının gerekmemesidir; bunun yerine testleri düz Java sınıflarında yazarsınız ve belirli test kurulumunu ve kısıtlamalarını belirtmek için ek açıklamalar kullanırsınız. Bu örnekte bu sınıfın Android JUnit4 testi olarak çalıştırılması gerektiğini anlatıyoruz.

@SmallTest ek açıklaması, test sınıfının tamamı için bir test boyutu belirledi: bu test sınıfına eklenen tüm test yöntemleri, bu test boyutu açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası sökme ve test sonrası sınıf sökme: JUnit4'teki setUp ve tearDown yöntemlerine benzer. Test açıklaması, gerçek teste açıklama eklemek için kullanılır.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

@Before ek açıklaması, ön test kurulumunu gerçekleştirmek için JUnit4 tarafından kullanılan yöntemlerde kullanılır. Bu örnekte kullanılmamasına rağmen, test sonrası sökme işlemi için @After da bulunmaktadır. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve daha sonra sökmek için JUnit4 tarafından kullanılan yöntemlerde kullanılabilir. Sınıf kapsamı kurulumu ve sökme yöntemlerinin statik olması gerektiğini unutmayın.

Test yöntemlerine gelince, JUnit'in önceki sürümünden farklı olarak, artık yöntem adını test ile başlatmaları gerekmiyor, bunun yerine her birinin @Test ile açıklanması gerekiyor. Her zamanki gibi, test yöntemleri herkese açık olmalı, dönüş değeri bildirmemeli, parametre almamalı ve istisnalar atabilir.

        Context context = InstrumentationRegistry.getTargetContext();

JUnit4 testleri artık ortak bir temel sınıf gerektirmediğinden, artık temel sınıf yöntemleri aracılığıyla getContext() veya getTargetContext() yoluyla Context örneklerini elde etmek gerekli değildir; bunun yerine yeni test çalıştırıcısı bunları, enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry aracılığıyla yönetir. Bu sınıf aracılığıyla şunları da arayabilirsiniz:

  • getInstrumentation() : Instrumentation sınıfının örneği
  • getArguments() : am instrument -e <key> <value> yoluyla aktarılan komut satırı argümanları

Yerel olarak derleyin ve test edin

En yaygın kullanım durumları için Atest'i kullanın.

Daha yoğun özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.