Android uygulamalarını test etmenin temelleri

Bu sayfada, Android uygulamalarını test etmenin temel ilkeleri en iyi uygulamalara ve bunların faydalarına değineceğiz.

Testin avantajları

Test yapmak, uygulama geliştirme sürecinin ayrılmaz bir parçasıdır. Testler çalıştırarak tutarlı bir şekilde, uygulamanızın doğruluğunu ve işlevselliğini doğrulayabilirsiniz. genel davranışı ve kullanılabilirliği açısından değerlendirilir.

Uygulamanızda gezinerek manuel olarak test edebilirsiniz. Şunu kullanabilirsiniz: farklı cihazlar ve emülatörler kullanıyorsanız, sistem dilini değiştirin ve her kullanıcı hatasından yararlanabilir.

Ancak, manuel testler kötü ölçeklenir ve gözden kaçabilir. regresyonlar olduğunu unutmayın. Otomatik test, araçların kullanılmasını içerir özellikleri geliştirmenizi sağlar. Bu yöntem, daha hızlı, daha tekrarlanabilir ve Geliştirme sürecinin başlarında uygulamanızla ilgili daha fazla işlem yapılabilir geri bildirim sağlar bahsedeceğim.

Android'deki test türleri

Mobil uygulamalar karmaşıktır ve birçok ortamda iyi performans göstermek zorundadır. Farklı 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: Bunu hızlı ve etkili bir şekilde yapıyor mu?
• Erişilebilirlik testi: Erişilebilirlik hizmetleriyle iyi çalışıyor mu?
• Uyumluluk testi: Her cihazda ve API düzeyinde iyi çalışıyor mu?

Kapsam

Testler boyuta veya izolasyon derecesine göre de değişiklik gösterir:

• Birim testleri veya küçük testler, uygulamanın yalnızca çok küçük bir bölümünü doğrular. (ör. yöntem veya sınıf) tıklayın.
• Uçtan uca testler veya büyük testler, uygulamanın daha büyük kısımlarını veya kullanıcı işlemleri akışı gibi gözlemlenebilir.
• Orta düzey testler bunların arasında yer alır ve iki veya daha az zaman arasındaki entegrasyonu daha fazla birim.

Testleri sınıflandırmanın birçok yolu vardır. Ancak en önemli fark testler burada yapılır.

Araçlı testler ile yerel testler

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

• Araçlı testler, fiziksel veya emülasyonlu bir Android cihazda çalıştırılır. Bu uygulama, web sitenize komutlar ve komutlar ekleyen bir test uygulamasıyla durumu okur. Araçlı testler genellikle kullanıcı arayüzü testleri, uygulamayı kullanıma sunma ve etkileşimde bulunabilirsiniz.
• Yerel testler geliştirme makinenizde veya bir sunucuda yürütülür, dolayısıyla ana makine tarafı testleri olarak da adlandırılır. Genellikle küçüktür ve hızlıdır, izleyiciyi izole eder. uygulamanın geri kalanında teste tabi olmalarını sağlayın.

Birim testlerinin hepsi yerel değildir ve bir cihazda uçtan uca testlerin hepsi çalıştırılmaz. Örneğin, örnek:

• Büyük yerel test: Yerel olarak çalışan bir Android simülasyon aracı kullanabilirsiniz. Robolectric olarak düşünün.
• Küçük araçlı test: Kodunuzun bir SQLite veritabanı gibi bir çerçeve özelliği kullanabilirsiniz. Bu testi şurada çalıştırabilirsiniz: SQLite'ın birden fazla sürümüyle entegrasyonu kontrol etmek için birden fazla cihazda kullanabilirsiniz.

Örnekler

Aşağıdaki snippet'ler, araçlı kullanıcı arayüzü testi, bir öğeyi tıklayan ve başka bir öğenin öğesi görüntülenir.

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

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

// 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ı) için bir birim testinin bir bölümünü gösterir testi):

// 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 dünyada, uygulamanızdaki her kod satırını her cihazda test etmeniz gerekir. tam olarak bunu göz önünde bulundurmalısınız. Maalesef bu yaklaşım çok yavaş ve maliyetliydi.

İyi bir test stratejisi, bir testin doğruluk düzeyi arasında ve güvenilirliğini inceleyeceğiz. Test ortamının benzerliği testin doğruluğunu gerçek bir cihaz belirler. Daha yüksek doğruluk oranı sunan testler veya fiziksel cihazın kendisinin test edilmesine yardımcı olur. Daha düşük doğruluk testleri JVM'ye yükleyebilirsiniz. Yüksek doğruluk oranı sunan testler genellikle daha yavaştır daha fazla kaynak gerektirdiğinden, her test yüksek kaliteli bir test değildir.

Güvenilir olmayan testler

Hatalar, doğru şekilde tasarlanmış ve uygulanmış test çalıştırmalarında bile ortaya çıkar. Örneğin, gerçek bir cihazda çalıştırıldığında, otomatik güncelleme ortasında olup başarısızlığa neden olabilir. Kodunuzdaki hassas yarış koşulları, yalnızca küçük bir zaman dilimi içinde ortaya çıkar. Sınav sonuçlarının% 100'ünü geçemeyen zaman kesintisiz.

Test edilebilir mimari

Test edilebilir uygulama mimarisi sayesinde kod, uygulamanızın ve bunların farklı bölümlerini ayrı olarak test edebilirsiniz. Test edilebilir mimariler ve okuma kolaylığı, ölçeklenebilirlik, ölçeklenebilirlik ve tekrar kullanılabilirlik.

Test edilemez bir mimari aşağıdakileri oluşturur:

• Daha büyük, daha yavaş, daha güvenilir olmayan testler. Birim test edilemeyen sınıflar, testlerine tabi tutulmasını sağlar.
• Farklı senaryoları test etmek için daha az fırsat. Büyük testler daha yavaş, Bu nedenle bir uygulamanın olası tüm durumlarını test etmek gerçekçi olmayabilir.

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

Ayrıştırma yaklaşımları

Geri kalanından bir işlevin, sınıfın veya modülün bir kısmını çıkarabiliyorsanız, daha kolay ve etkilidir. Bu uygulama, ayrıştı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 bölebilirsiniz. Şunları yapabilirsiniz: Ayrıca bir uygulamayı, özellik başına bir tane olacak şekilde modüllere bölebilirsiniz.
• Örneğin, parçalardan bahsedeceğiz. Bu sınıfları çerçeveye giriş noktaları olarak kullanın ve Kullanıcı arayüzünü ve iş mantığını Composable, ViewModel veya alan katmanıdır.
• İş 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ın değiştirilmesini kolaylaştırın. Örneğin, şunu kullanın: arayüzler oluşturmak sizin görevinizdir. Tekliflerinizi otomatikleştirmek ve optimize etmek için DI çerçevesi kullanmasanız bile bağımlılık yerleştirme.

Sonraki adımlar

Artık neden test etmeniz gerektiğini ve iki ana test türünü öğrendiğinize göre, Neleri test edebilirsiniz? başlıklı makaleyi okuyun.

Alternatif olarak, ilk testinizi oluşturmak ve yaparak öğrenmek istiyorsanız Kodlama testlerini test etme hakkında daha fazla bilgi edinin.