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

Kendi Enstrümantasyon Testleri Örneği

Bir enstrümantasyon testi başlatıldığında, hedef paketi enjekte edilen enstrümantasyon kodu ile yeniden başlatılır ve yürütme için başlatılır. Bunun bir istisnası, buradaki hedef paketin Android uygulama çerçevesinin kendisi yani android paketi android , çünkü bunu yapmak Android çerçevesinin yeniden başlatılması gereken paradoksal duruma yol açacaktır, bu da enstrümantasyon da dahil olmak üzere sistem işlevlerini destekler kendisi.

Bu, bir enstrümantasyon testinin yürütme için kendini Android çerçevesine, yani sistem sunucusuna enjekte edemeyeceğ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 aracılığıyla açığa çıkarılan yüzeyleri çağırabilir. Bu test kategorisi için, belirli bir paketi hedeflemek anlamlı değildir. Kendi tanımlanan nedenle, bu tür instrumentations için 's alışılmış, kendi testi uygulama paketi hedef ilan edilecek <manifest> etiketinin AndroidManifest.xml .

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

  • Test için gerekli paket aktiviteleri.
  • Kullanıcı kimliğini sistemle paylaşın.
  • Platform anahtarı ile imzalanın.
  • Kamu SDK'sından ziyade çerçeve kaynağına karşı derlenin.

Bu enstrümantasyon testleri kategorisine bazen kendi kendine enstrümantasyon denir. Platform kaynağındaki kendi kendine enstrümantasyon testlerine bazı örnekler:

Burada ele alınan örnek, kendi test uygulama paketinde hedef paketi ayarlanmış yeni bir enstrümantasyon testi yazmaktır. Bu kılavuz örnek olarak aşağıdaki testi kullanır:

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

Kaynak bir konuma karar verme

Genellikle ekibinizin kodu kontrol etmek için önceden belirlenmiş yerler ve test eklenecek yerler vardır. Çoğu takım tek bir git deposuna sahiptir veya başka bir ekiple 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ğu varsayıldığında, çoğu bileşenin altında src ve tests klasörleri ve AndroidManifest.xml manifest dosyası olan Android.mk (veya ek .mk dosyalarına bölünmüş) gibi bazı ek dosyalar vardır. AndroidManifest.xml ve test yapılandırma dosyası 'AndroidTest.xml'.

Yepyeni bir test eklediğiniz için, bileşen src yanında tests dizini oluşturmanız ve bunu içerikle doldurmanız gerekir.

Bazı durumlarda, farklı test paketlerini bireysel uygulamalara paketleme gereği nedeniyle ekibiniz tests altındaki diğer dizin yapılarına sahip olabilir. Ve bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekir.

Yapısından bağımsız olarak, tests dizinini veya yeni oluşturulan alt dizini, örnek gerrit değişikliğindeki instrumentation dizinindekine benzer dosyalarla doldurursunuz. Aşağıdaki bölümler her bir dosyanın ayrıntılarını açıklayacaktır.

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. Platform_testing / testing / example / instrument / AndroidManifest.xml adresindeki örneğe bakın.

Kolaylık sağlamak için bir fotoğraf eklenmiştir:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

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

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>
 

Bazıları manifest dosyasındaki açıklamaları seçer:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >
 

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.

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.

 android:sharedUserId="android.uid.system"
 

Bu, kurulum sırasında bu apk'ye çekirdek platformla aynı kullanıcı kimliği, yani çalışma zamanı kimliği verilmesi gerektiğini bildirir. Bunun, çekirdek platformla aynı sertifika ile imzalanan LOCAL_CERTIFICATE bağlı olduğunu unutmayın (yukarıdaki bölümdeki LOCAL_CERTIFICATE bakın), ancak bunlar farklı kavramlardır:

  • bazı izinler veya API'lar imza korumalıdır, bu da aynı imza sertifikasını gerektirir
  • bazı izinler veya API'lar, arayanın system kullanıcı kimliğini gerektirir; bu, çekirdek platformun kendisinden ayrı bir paketse, çağrı paketinin kullanıcı kimliğini system paylaşmasını gerektirir.
 <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="android.test.example.helloworld"
 

Buradaki targetPackage öğesinin, bu dosyanın manifest etiketinde bildirilen package özniteliği ile aynı şekilde bildirildiğini fark etmiş olabilirsiniz. Test temellerinde belirtildiği gibi, bu enstrümantasyon testi kategorisi genellikle çerçeve API'lerini test etmek için tasarlanmıştır, bu nedenle kendilerinden başka belirli bir hedeflenmiş uygulama paketine sahip olmaları çok anlamlı değildir.

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, bkz. Basit Test Yapılandırması .

Karmaşık yapılandırma dosyası

Bu daha karmaşık durumlar 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. /Platform_testing/tests/example/instrumentation/AndroidTest.xml adresindeki örneğe bakın.

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

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="HelloWorldTests.apk"/>
</target_preparer>
 

Bu, Ticaret Federasyonu'na HelloWorldTests.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="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ı belirtir ve yürütülecek aygıttaki pakete ve bu durumda JUnit olan test çalıştırıcı çerçevesine geçer.

Daha fazla bilgi için, bkz. Test Modülü Yapılandırmaları .

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. /Platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java adresindeki örneğe bakın.

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

 @RunWith(JUnit4.class)
public class HelloWorldTest {
 

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 JUnit4 testi olarak çalıştırılması gerektiğini bildiriyoruz.

     @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ı @After tarafından yöntemlerde test öncesi kurulum ve test sonrası yıkım gerçekleştirmek için kullanılır. Benzer şekilde, @BeforeClass ve @AfterClass ek açıklamaları, JUnit4 tarafından yöntemlerde, bir test sınıfındaki tüm testleri yürütmeden önce kurulum gerçekleştirmek ve daha sonra yıkmak için kullanılır. 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.

Önemli : Test yöntemlerinin kendilerine @Test ek açıklaması @Test ; ve testler APCT ile yürütülecek için, bu deney boyutları ile açıklamalı gereken dikkat edin: Örnek açıklamalı yöntem testHelloWorld olarak @SmallTest . Ek açıklama yöntem kapsamında veya sınıf kapsamında uygulanabilir.

instrumentation erişim

Temel merhaba dünya örneğinde yer almasa da, bir Android testinin erişim Instrumentation örneği gerektirmesi oldukça yaygındır: bu, uygulama bağlamlarına, etkinlik yaşam döngüsü ile ilgili test API'larına ve daha fazlasına erişim sağlayan temel API arayüzüdür.

JUnit4 artık testleri aynı temel sınıfa gerektirdiğinden, bu elde etmek artık gerekli Instrumentation yoluyla örneğini InstrumentationTestCase#getInstrumentation() yerine, yeni test koşucu yoluyla yönetir InstrumentationRegistry enstrümantasyon çerçevesi tarafından oluşturulan bağlamsal ve çevre kurulum saklanır.

Örneğini erişmek için Instrumentation sınıfında, sadece statik yöntem çağrı getInstrumentation() üzerine InstrumentationRegistry sınıfının:

 Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()
 

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.