Android uygulamalarını test etmenin temelleri

Bu sayfada, Android uygulamalarını test etmenin temel ilkeleri, merkezi en iyi uygulamalar ve bunların avantajları özetlenmektedir.

Test etmenin avantajları

Test yapmak, uygulama geliştirme sürecinin ayrılmaz bir parçasıdır. Uygulamanızı herkese açık olarak yayınlamadan önce tutarlı bir şekilde testler çalıştırarak uygulamanızın doğruluğunu, işlevsel davranışını ve kullanılabilirliğini doğrulayabilirsiniz.

Uygulamanızda gezinerek manuel olarak test edebilirsiniz. Farklı cihazlar ve emülatörler kullanabilir, sistem dilini değiştirebilir ve her kullanıcı hatasını oluşturmaya ya da her kullanıcı akışını geçmeye çalışabilirsiniz.

Ancak, manuel testlerin ölçeği yetersizdir ve uygulamanızın davranışındaki regresyonları gözden kaçırmanız mümkündür. Otomatik test sizin için testler yapan araçların kullanılmasını içerir. Bu araçlar daha hızlı, tekrarlanabilir ve genellikle geliştirme sürecinin daha erken aşamalarında uygulamanızla ilgili daha uygulanabilir geri bildirimler sağlar.

Android'deki test türleri

Mobil uygulamalar karmaşıktır ve birçok ortamda iyi bir şekilde çalışmalıdır. Bu nedenle, birçok test türü vardır.

Konu

Örneğin, konuya bağlı olarak farklı test türleri vardır:

  • İşlevsel test: Uygulamam gerekeni yapıyor mu?
  • Performans testi: Hızlı ve etkili şekilde gerçekleştirilir mi?
  • Erişilebilirlik testi: Erişilebilirlik hizmetleriyle iyi çalışıyor mu?
  • Uyumluluk testi: Her cihazda ve API düzeyinde düzgün çalışıyor mu?

Kapsam

Testler, boyuta veya izolasyon derecesine bağlı olarak da değişiklik gösterir:

  • Birim testleri veya küçük testler, uygulamanın yalnızca çok küçük bir bölümünü (ör. yöntem veya sınıf) doğrular.
  • Uçtan uca testler veya büyük testler, aynı anda tüm ekran veya kullanıcı işlemleri akışı gibi uygulamanın daha büyük bölümlerini doğrular.
  • Arada orta düzeyde testler vardır ve iki veya daha fazla birim arasındaki entegrasyonu kontrol edin.
Testler küçük, orta veya büyük olabilir.
Şekil 1: Tipik bir uygulamada kapsamları test edin.

Testleri sınıflandırmanın birçok yolu vardır. Ancak, uygulama geliştiriciler için en önemli fark testlerin nerede yürütüldüğüdür.

Enstrümanlı ve yerel testler

Testleri bir Android cihazda veya başka bir bilgisayarda çalıştırabilirsiniz:

  • Araçlı testler fiziksel veya emülasyonlu bir Android cihazda çalıştırılır. Uygulama, komut ekleyen ve durumu okuyan bir test uygulamasıyla birlikte derlenip yüklenir. Araçlı testler genellikle kullanıcı arayüzü testleri, bir uygulamayı başlatma ve ardından etkileşimde bulunmadır.
  • Yerel testler, geliştirme makinenizde veya bir sunucuda yürütüleceğinden ana makine tarafı testleri olarak da adlandırılır. Genellikle küçük ve hızlıdırlar, test edilen kişi, uygulamanın geri kalanından izole edilir.
Testler, bir cihazda donanımlı testler veya geliştirme makinenizde yerel testler olarak çalıştırılabilir.
Şekil 2: Nerede çalıştıklarına bağlı olarak farklı test türleri.

Tüm birim testleri yerel değildir ve tüm uçtan uca testler bir cihazda çalıştırılmaz. Örneğin:

  • Büyük yerel test: Robofactric gibi yerel olarak çalışan bir Android simülatörü kullanabilirsiniz.
  • Küçük ölçekli test: Kodunuzun SQLite veritabanı gibi bir çerçeve özelliğiyle iyi çalıştığını doğrulayabilirsiniz. Birden fazla SQLite sürümüyle entegrasyonu kontrol etmek için bu testi birden fazla cihazda çalıştırabilirsiniz.

Örnekler

Aşağıdaki snippet'ler, bir öğeyi tıklayan ve başka bir öğenin görüntülendiğini doğrulayan araçlı kullanıcı arayüzü testinde kullanıcı arayüzü ile nasıl etkileşimde bulunulacağını gösterir.

Espresso

// When the Continue button is clicked
onView(withText("Continue"))
    .perform(click())

// Then the Welcome screen is displayed
onView(withText("Welcome"))
    .check(matches(isDisplayed()))

Kullanıcı arayüzü oluşturun

// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()

// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()

Bu snippet, ViewModel (yerel, ana makine tarafı testi) için bir birim testinin bir bölümünü gösterir.

// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)

// When data is loaded
viewModel.loadData()

// Then it should be exposing data
assertTrue(viewModel.data != null)

Test stratejisi tanımlama

İdeal bir durumda, uygulamanızdaki her kod satırını uygulamanızın uyumlu olduğu her cihazda test etmeniz gerekir. Ne yazık ki bu yaklaşım çok yavaş ve maliyetli.

İyi bir test stratejisi testin doğruluğu, hızı ve güvenilirliği arasında uygun bir denge kurar. Test ortamının gerçek bir cihaza benzerliği testin doğruluğunu belirler. Daha yüksek doğruluk oranı sunan testler, emüle edilmiş cihazlarda veya fiziksel cihazın kendisinde gerçekleştirilir. Yerel iş istasyonunuzun JVM'sinde daha düşük doğruluk testleri yapılabilir. Yüksek doğruluklu testler genellikle daha yavaştır ve daha fazla kaynak gerektirir. Bu nedenle, her test yüksek doğruluklu bir test olmamalıdır.

Güvenilir olmayan testler

Doğru şekilde tasarlanmış ve uygulanmış test çalıştırmalarında bile hatalar ortaya çıkar. Örneğin, gerçek bir cihazda test çalıştırırken, testin ortasında otomatik güncelleme başlayıp başarısız olabilir. Kodunuzdaki hafif yarış koşulları, zamanın yalnızca küçük bir bölümünde gerçekleşebilir. Sürenin% 100'ünü geçemeyen testler kesintisiz olur.

Test edilebilir mimari

Test edilebilir uygulama mimarisiyle kod, farklı bölümlerini tek başına kolayca test etmenize olanak tanıyan bir yapıyı izler. Test edilebilir mimarilerin daha iyi okunabilirlik, sürdürülebilirlik, ölçeklenebilirlik ve yeniden kullanılabilirlik gibi başka avantajları da vardır.

Test edilemez bir mimari şunları üretir:

  • Daha büyük, daha yavaş, daha güvenilir testler. Birim testi yapılamayan sınıfların, daha büyük entegrasyon veya kullanıcı arayüzü testlerinin kapsamında olması gerekebilir.
  • Farklı senaryoları test etmek için daha az fırsat. Daha büyük testler daha yavaştır. Bu nedenle, bir uygulamanın tüm olası durumlarını test etmek gerçekçi olmayabilir.

Mimari yönergeleri hakkında daha fazla bilgi edinmek için uygulama mimarisi kılavuzuna bakın.

Ayrıştırma yaklaşımları

Bir işlevin, sınıfın veya modülün bir kısmını diğerlerinden çıkarabiliyorsanız bunu test etmek daha kolay ve etkili olur. Bu uygulama, ayırma olarak bilinir ve test edilebilir mimari için en önemli kavramdır.

Yaygın ayırma teknikleri şunlardır:

  • Bir uygulamayı Sunu, Alan ve Veri gibi katmanlara ayırabilirsiniz. Ayrıca bir uygulamayı, özellik başına bir tane olacak şekilde modüllere bölebilirsiniz.
  • Etkinlikler ve parçalar gibi büyük bağımlılıkları olan varlıklara mantık eklemekten kaçının. Bu sınıfları çerçeveye giriş noktaları olarak kullanın ve kullanıcı arayüzü ve iş mantığını Composable, ViewModel veya alan adı katmanı gibi başka bir yere taşıyın.
  • İş mantığı içeren sınıflarda doğrudan çerçeve bağımlılıklarından kaçının. Örneğin, ViewModels'de Android Contexts kullanmayın.
  • Bağımlılıkları değiştirilmesini kolaylaştırın. Örneğin, somut uygulamalar yerine arayüzler kullanın. DI çerçevesi kullanmasanız bile Bağımlılık ekleme'yi kullanın.

Sonraki adımlar

Neden test etmeniz gerektiğini ve iki ana test türünü öğrendiğinize göre Neleri test etmelisiniz? bölümünü okuyabilirsiniz.

Alternatif olarak, ilk testinizi oluşturup uygulayarak öğrenmek isterseniz Kod laboratuvarlarını test etme konusuna göz atın.