Uygulama örneğini hedefleme

Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedefleyen testlerden çok farklı değildir. Burada, test uygulamasının ve aynı sertifika ile imzalanması gerekir. bu en iyi uygulamadır.

Bu kılavuzun, Google Analytics 4'te Google Cloud'un kullanımı ile ilgili platform kaynak ağacı iş akışı. Değilse lütfen Şartlar'a bakın. Burada ele alınan örnek, hedef ile yeni bir araç testi yazmaktır. paketinin kendi test uygulama paketinde ayarlanır. kavramak için lütfen Platform testiyle ilgili giriş bölümünü okuyun.

Bu kılavuzda, örnek olması için aşağıdaki test kullanılmaktadır:

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

Genel bir fikir edinmek için önce koda göz atmanız önerilir. inceleyin.

Kaynak konuma karar verme

Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, test kaynak kodunun platform kaynak ağacındaki bileşen kaynak dizininizin kök dizininin altındaki bir tests dizine yerleştirilmesi önerilir.

Kaynak konumla ilgili daha fazla tartışmaya ulaşmak için kendi kendine enstrümantasyon testlerini kullanın.

Manifest dosyası

Normal bir uygulamada olduğu gibi, her araç test modülünün belirli bir manifest dosyası olarak kaydedin. Dosyayı AndroidManifest.xml olarak adlandırıp sonraki adımda sağlarsanız test modülü için Android.mk adresine gönderirseniz bu modül BUILD_PACKAGE temel oluşturma dosyası.

Devam etmeden önce Uygulama Manifesti'ne Genel Bakış bölümünü incelemeniz önemle tavsiye edilir.

Bu rapor, bir manifest dosyasının temel bileşenlerine ve bunların temel bileşenlerine işlevler sunar.

Örnek değer değişikliği için manifest dosyasının en son sürümüne erişilebilir Yer: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml

Kolaylık sağlamak için 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>

Bazı açıklamalar manifest dosyasında seçilir:

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

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.

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() ve çeşitli pm aboneleri ile etkileşimde bulunmak için kullandığınız aynı komutlarını adb shell aracılığıyla kontrol edin.

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

<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, aracın hedef paketini com.android.shell olarak ayarlar. Araç am instrument komutuyla çağrıldığında çerçeve com.android.shell işlemini yeniden başlatır ve araç kodunu teste tabi tutulmasıdır. Bu aynı zamanda test kodunda, çalışan tüm sınıf örneklerine erişebilir ve bu ve durumu değiştirebilmek, deney sırasında kullanılan test kancalarına bağlıdır.

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 değildir. Ayrıntılar için Basit Test Yapılandırması başlıklı makaleyi inceleyin.

Karmaşık yapılandırma dosyası

Daha karmaşık testler için ayrıca bir test yapılandırması yazmanız gerekir dosyası olarak da kullanabilirsiniz.

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.

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

Kolaylık sağlamak amacıyla 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ı 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. 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="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ı belirtir ve yürütülecek cihazdaki pakete geçer ve test çalıştırıcı, JUnit'i seçin.

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

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.

Örnek değer değişikliği için 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ı vardır.

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

JUnit4'teki önemli bir fark, testlerin yaygın bir temel test sınıfından devralmak; bunun yerine, testleri düz Java ile yazarsınız ve kısıtlamaları belirtmek için ek açıklama kullanır. İçinde bu örnekte, bu sınıfın Android 360'da Android JUnit4 testi.

@SmallTest ek açıklaması, test sınıfının tamamı için bir test boyutu belirtti: tümü bu test sınıfına eklenen test yöntemleri bu test boyutu ek açıklamasını devralır. test öncesi sınıf kurulumu, test sonrası ortadan kaldırma ve test sonrası sınıfın ortadan kaldırılması: 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ı şuralarda kullanılabilir: test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek için JUnit4 tarafından uygulanan yöntemler, yıkabilirsiniz. Sınıf kapsamı kurulumu ve sökme yöntemlerinin statik olmalıdır.

Test yöntemlerinde ise, JUnit'in önceki sürümünün aksine, yöntem adını test ile başlatmak için her birine ek açıklama eklemeniz gerekir @Test ile. 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 getContext() veya üzerinden Context örneği almak için gereklidir Temel sınıf yöntemleriyle getTargetContext(); bunun yerine yeni test çalıştırıcısı bunları InstrumentationRegistry üzerinden yönetir enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulum saklanıyor. Bu sınıf üzerinden şunları da arayabilirsiniz:

• getInstrumentation(): Instrumentation sınıfına örnek
• getArguments(): -e <key> <value> aracılığıyla am instrument'a iletilen komut satırı bağımsız değişkenleri

Yerel olarak derleyip test edin

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.