Google, Siyah topluluklar için ırksal eşitliği ilerletmeye kararlıdır. Nasıl olduğunu gör.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

Uygulama Örneğini Hedefleme

Bu enstrümantasyon testi kategorisi, normal Android uygulamalarını hedefleyenlerden farklı değildir. Enstrümantasyonu içeren test uygulamasının, hedeflediği uygulama ile aynı sertifika ile imzalanması gerektiğini belirtmek gerekir.

Bu kılavuzun, platform kaynak ağacı iş akışında zaten bazı bilgilere sahip olduğunuzu varsaydığını unutmayın. Değilse, lütfen https://source.android.com/source/requirements adresine bakın. Burada ele alınan örnek, kendi test uygulama paketinde hedef paketi ayarlanmış yeni bir enstrümantasyon testi yazmaktır. Konsept hakkında bilginiz yoksa, lütfen Platform test girişini okuyun.

Bu kılavuz, örnek olarak hizmet etmek için aşağıdaki testi kullanır:

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

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

Kaynak bir konuma karar verme

Enstrümantasyon testi bir uygulamayı hedefleyeceğinden, kural test kaynak kodunu platform kaynak ağacındaki bileşen kaynak dizininizin kökünün altındaki bir tests dizinine yerleştirmektir.

Kendi kendine enstrümantasyon testleri için uçtan uca örnekte kaynak konumu hakkında daha fazla tartışmaya bakın.

Bildirim dosyası

Tıpkı normal bir uygulama gibi, her enstrümantasyon test modülünün açık bir dosyaya ihtiyacı vardır. Dosyayı AndroidManifest.xml ve test modülünüz için Android.mk yanına sağlarsanız, BUILD_PACKAGE çekirdek makefile tarafından otomatik olarak dahil edilir.

Daha fazla ilerlemeden önce, önce Uygulama Bildirimine Genel Bakış'ı incelemenizi öneririz.

Bu, bir bildirim dosyasının temel bileşenlerine ve işlevlerine genel bir bakış sağlar.

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

Kolaylık sağlamak için bir fotoğraf 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ıları manifest dosyasındaki açıklamaları seçer:

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

package özniteliğ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ı, bu paket adına sahip yalnızca bir uygulama yükleyebilir.

Bu, test edilen uygulama paketinden bağımsız olarak bir test uygulama paketi olduğundan, farklı bir paket adı kullanılmalıdır: ortak bir kural, .test sonekini eklemektir.

Ayrıca, bu package özniteliği ComponentName#getPackageName() döndürdüğü ile aynıdır ve adb shell aracılığıyla çeşitli pm alt komutlarıyla etkileşimde bulunmak için kullandığınızla aynıdır.

Ayrıca, paket adının genellikle bir Java paket adıyla aynı stilde olmasına rağmen, aslında bununla çok az ilgisi olduğunu unutmayın. Diğer bir deyişle, uygulama (veya test) paketiniz paket adlarına sahip sınıflar içerebilir, ancak diğer yandan, sadeliği tercih edebilir ve uygulamanızda en üst düzey Java paket adınızı alabilir veya uygulama paketi adıyla aynı testi yapabilirsiniz.

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

İlgili sınıflar ayrı bir çerçeve kavanoz kitaplığı dosyasında paketlendiğinden, tüm Enstrümantasyon testleri için bu gereklidir, bu nedenle 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.tests ayarlar. Enstrümantasyon am instrument komutu ile çağrıldığında, çerçeve com.android.shell.tests işlemini yeniden başlatır ve enstrümantasyon kodunu test yürütme sürecine enjekte eder. Bu ayrıca, test kodunun test edilen uygulamada çalışan tüm sınıf örneklerine erişebileceği ve durumu değiştirebilecek durumun, test edilen kancalara bağlı olduğu anlamına gelir.

Basit yapılandırma dosyası

Her yeni test modülünün derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatları ile yönlendirmek için bir yapılandırma dosyası 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ı olan Ticaret Federasyonu için bir test yapılandırma dosyası yazmanız gerekir.

Test yapılandırması, test sınıfını sağlamak için özel aygıt kurulum seçeneklerini ve varsayılan bağımsız değişkenleri belirtebilir.

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

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

Bazıları test yapılandırma dosyasındaki açıklamaları seçer:

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

Bu, Ticaret Federasyonu'na ShellTests.apk dosyasını belirtilen bir target_preparer kullanarak hedef aygıta yüklemesini bildirir. Ticaret Federasyonu'ndaki geliştiriciler için birçok 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ı belirtir ve yürütülecek aygıttaki pakete ve bu durumda JUnit olan test çalıştırıcı çerçevesine geçer.

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

JUnit4 özellikleri

Test koşucusu olarak android-support-test kitaplığını kullanmak, yeni JUnit4 stili test sınıflarının benimsenmesini sağlar ve örnek gerrit değişikliği, özelliklerinin bazı temel kullanımını içerir.

Örnek gerrit değişimi için en son kaynak koduna şu adresten erişilebilir: frameworks / base / Packages / Shell / testler / src / com / android / shell / BugreportReceiverTest.java

Test modelleri genellikle bileşen ekiplerine özgü olmakla birlikte, genel olarak kullanışlı kullanım kalıpları vardır.

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

JUnit4'te önemli bir fark, testlerin artık ortak bir temel test sınıfından miras alınması gerekmediğidir; 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 bir Android JUnit4 testi olarak çalıştırılması gerektiğini bildiriyoruz.

@SmallTest ek açıklaması tüm test sınıfı için bir test boyutu @SmallTest : bu test sınıfına eklenen tüm test yöntemleri bu test boyutu ek açıklamasını devralır. test öncesi kurulum, test sonrası parçalama ve test sonrası parçalanma: setUp ve tearDown yöntemlerine benzer. Test notu, gerçek teste not eklemek için kullanılır.

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

@Before ek açıklaması, JUnit4 tarafından ön test kurulumunu yapmak için yöntemlerde kullanılır. Bu örnekte kullanılmasa da, test sonrası @After için @After sonra da var. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, JUnit4 tarafından, bir test sınıfındaki tüm testleri yürütmeden önce kurulumu gerçekleştirmek ve daha sonra sökmek için yöntemlerde kullanılabilir. Sınıf kapsamı kurulum ve yıkma 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ı test ile başlatmaları gerekmez, bunun yerine her birinin @Test ile @Test gerekir. 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 yoluyla getContext() veya getTargetContext() yoluyla Context örnekleri elde etmek gerekli değildir; bunun yerine, yeni test koşucusu bunları enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevresel kurulumun depolandığı InstrumentationRegistry yoluyla yönetir. Bu sınıf aracılığıyla şunları da arayabilirsiniz:

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

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.