Bu sayfada, temel en iyi uygulamalar ve bunların avantajları da dahil olmak üzere Android uygulamalarını test etmenin temel ilkeleri özetlenmiştir.
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 onaylayabilirsiniz.
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 testler kötü ölçeklenir ve uygulamanızın davranışındaki regresyonları kolayca gözden kaçırabilir. Otomatik test, sizin için test yapan araçların kullanılmasını içerir. Bu araçlar daha hızlı, daha tekrarlanabilir ve genellikle geliştirme sürecinin erken aşamalarında uygulamanızla ilgili uygulanabilir geri bildirimler sağlar.
Android'deki test türleri
Mobil uygulamalar karmaşıktır ve birçok ortamda iyi performans göstermek zorundadır. Bu nedenle, pek ç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 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ü (ör. yöntem ya da 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 ayrım, testlerin nerede gerçekleştirildiğidir.
Araçlı testler ile 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. Enstrümante testler genellikle bir uygulamayı başlatıp uygulamayla etkileşime geçen kullanıcı arayüzü testleridir.
- 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 araçlı 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'te, bir ViewModel (yerel, ana makine tarafında test) için birim testinin bir kısmı gösterilmektedir:
// 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. Ayrıştırma olarak bilinen bu uygulama, 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. 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ü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ı kullanmaktan 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.