Bu sayfada, merkezi en iyi uygulamalar ve bunların avantajları da dahil olmak üzere Android uygulamalarını test etmenin temel ilkeleri özetlenmektedir.
Testin 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 testle 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ülasyon araçları kullanabilir, sistem dilini değiştirebilir, her kullanıcı hatasını oluşturmaya çalışabilir veya her kullanıcı akışında gezinebilirsiniz.
Ancak manuel test ölçek açısından yetersizdir ve uygulamanızın davranışındaki gerilemelerin gözden kaçırılması kolay olabilir. Otomatik test, sizin için testleri gerçekleştiren araçları kullanmayı içerir. Bu yöntem daha hızlı ve daha tekrarlanabilirdir ve genellikle geliştirme sürecinin daha erken aşamalarında uygulamanızla ilgili daha fazla uygulanabilir geri bildirim sağlar.
Android'deki test türleri
Mobil uygulamalar karmaşıktır ve birçok ortamda iyi ç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: İşlemi hızlı ve verimli bir şekilde gerçekleştiriyor 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 tecrit derecesine göre de değişiklik gösterir:
- Birimi testler veya küçük testler, uygulamanın yalnızca çok küçük bir bölümünü (ör. bir yöntem veya sınıf) doğrular.
- Uçtan uca testler veya büyük testler, ekranın tamamı veya kullanıcı akışı gibi uygulamanın daha büyük bölümlerini aynı anda doğrular.
- Orta düzey testler, iki veya daha fazla birim arasındaki entegrasyonu kontrol eder.
Testleri sınıflandırmanın birçok yolu vardır. Ancak uygulama geliştiriciler için en önemli fark, testlerin çalıştırıldığı yerdir.
Araçla testler ve yerel testler
Testleri Android cihazda veya başka bir bilgisayarda çalıştırabilirsiniz:
- Araç destekli testler, fiziksel veya taklit edilmiş bir Android cihazda çalışır. Uygulama, komutlar ekleyen ve durumu okuyan bir test uygulaması ile birlikte derlenip yüklenir. Araçlı testler genellikle kullanıcı arayüzü testleri, bir uygulamanın başlatılması ve ardından uygulamayla etkileşimde bulunulmasıdır.
- Yerel testler, geliştirme makinenizde veya bir sunucuda yürütülür. Bu nedenle bunlara ana makine tarafı testleri de denir. Genellikle küçük ve hızlı olan bu testler, test edilen öğeyi uygulamanın geri kalanından ayırır.
Tüm birim testleri yerel değildir ve tüm uçtan uca testler cihazda çalıştırılmaz. Örneğin:
- Büyük yerel test: Robolectric gibi yerel olarak çalışan bir Android simülasyon aracı kullanabilirsiniz.
- Küçük enstrümante test: Kodunuzun SQLite veritabanı gibi bir çerçeve özelliğiyle iyi çalıştığını doğrulayabilirsiniz. SQLite'in birden fazla sürümüyle entegrasyonu kontrol etmek için bu testi birden fazla cihazda çalıştırabilirsiniz.
Örnekler
Aşağıdaki snippet'lerde, bir öğeyi tıklayıp başka bir öğenin gösterildiğini doğrulayan donanımla desteklenmiş kullanıcı arayüzü testinde kullanıcı arayüzüyle nasıl etkileşim kurulacağı gösterilmektedir.
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Oluşturma kullanıcı arayüzü
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
Bu snippet, bir ViewModel için birim testinin bir bölümünü gösterir (yerel, ana makine tarafı 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 edilebilir mimari
Test edilebilir bir uygulama mimarisine sahip kod, farklı bölümlerini ayrı ayrı kolayca test etmenize olanak tanıyan bir yapıya sahiptir. 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 aşağıdakileri oluşturur:
- Daha büyük, daha yavaş ve daha güvenilir olmayan testler. Birim testi yapılamayan sınıflar daha büyük entegrasyon testleri veya kullanıcı arayüzü testleriyle kapsanmalıdır.
- Farklı senaryoları test etme fırsatı daha azdır. 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ı geri kalanından ayıklayabiliyorsanız test etmek daha kolay ve daha etkili olur. Bu uygulama, birbirinden ayırma olarak bilinir ve test edilebilir mimari için en önemli kavramdır.
Yaygın ayırma teknikleri şunlardır:
- Bir uygulamayı Sunum, Alan ve Veri gibi katmanlara bölün. Ayrıca, bir uygulamayı her özellik için bir tane olacak şekilde modüllere de ayırabilirsiniz.
- Etkinlikler ve parçalar gibi büyük bağımlılıklara sahip öğelere mantık eklemekten kaçının. 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ına 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ın değiştirilmesini kolaylaştırın. Örneğin, somut uygulamalar yerine arayüzler kullanın. Bir DI çerçevesi kullanmıyorsanız bile bağımlılık ekleme özelliğini kullanın.
Sonraki adımlar
Neden test etmeniz gerektiğini ve iki ana test türünü öğrendiğinize göre Neleri test etmelisiniz? başlıklı makaleyi okuyabilir veya Test stratejileri hakkında bilgi edinebilirsiniz.
Alternatif olarak, ilk testinizi oluşturmak ve yaparak öğrenmek istiyorsanız Codelab'leri test etme sayfasına göz atın.