Bu sayfada, temel 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 onaylayabilirsiniz.
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 testler iyi ölçeklenmez ve uygulamanızın davranışındaki gerilemeleri gözden kaçırmak kolay olabilir. Otomatik test, testleri sizin yerinize yapan araçların kullanılmasını içerir. Bu yöntem daha hızlıdır, daha tekrarlanabilir ve genellikle geliştirme sürecinin başlarında uygulamanız hakkında daha fazla harekete geçirici 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, yapması gerekenleri yapıyor mu?
- Performans testi: Hızlı ve verimli bir şekilde mi yapıyor?
- Erişilebilirlik testi: Erişilebilirlik hizmetleriyle iyi çalışıyor mu?
- Uyumluluk testi: Uygulama her cihazda ve API düzeyinde iyi çalışıyor mu?
Kapsam
Testler ayrıca boyuta veya izolasyon derecesine göre de değişir:
- Birim testleri 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, uygulamanın daha büyük bölümlerini (ör. ekranın tamamı veya kullanıcı akışı) aynı anda doğrular.
- Orta 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 nerede çalıştırıldığıdır.
Araçlı testler ve yerel testler
Android cihazda veya başka bir bilgisayarda testler çalıştırabilirsiniz:
- Enstrümanlı testler, fiziksel veya emüle edilmiş bir Android cihazda çalışır. Uygulama, komutlar yerleştiren ve durumu okuyan bir test uygulamasıyla birlikte oluşturulup yüklenir. Enstrümanlı testler genellikle kullanıcı arayüzü testleridir. Bu testlerde bir uygulama başlatılır ve ardından uygulamayla etkileşim kurulur.
- Yerel testler, geliştirme makinenizde veya bir sunucuda yürütülür. Bu nedenle ana makine tarafı testleri olarak da adlandırılır. Genellikle küçük ve hızlıdırlar. Test edilen konuyu uygulamanın geri kalanından ayırırlar.
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: Yerel olarak çalışan bir Android simülatörü (ör. Robolectric) kullanabilirsiniz.
- Küçük enstrümantasyonlu test: Kodunuzun, SQLite veritabanı gibi bir çerçeve özelliğiyle iyi çalıştığını doğrulayabilirsiniz. SQLite'ın birden fazla 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 bir enstrümanlı kullanıcı arayüzü testinde kullanıcı arayüzüyle 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()))
Compose 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'in (yerel, ana makine tarafı testi) 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 edilebilir mimari
Test edilebilir bir uygulama mimarisinde kod, farklı bölümlerini ayrı ayrı kolayca test etmenize olanak tanıyan bir yapıyı izler. Test edilebilir mimariler; daha iyi okunabilirlik, sürdürülebilirlik, ölçeklenebilirlik ve yeniden kullanılabilirlik gibi başka avantajlar da sunar.
Test edilemeyen bir mimari aşağıdakileri üretir:
- Daha büyük, daha yavaş ve daha güvenilmez testler. Birim testi yapılamayan sınıfların daha büyük entegrasyon testleri veya kullanıcı arayüzü testleriyle kapsanması gerekebilir.
- Farklı senaryoları test etmek için daha az fırsat sunar. Daha büyük testler daha yavaştır. 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 mimarisi kılavuzuna bakın.
Bağlantıyı kaldırma yaklaşımları
Bir işlevin, sınıfın veya modülün bir bölümünü geri kalanından ayırabiliyorsanız bu bölümü test etmek daha kolay ve etkili olur. Bu uygulama, ayrıştırma olarak bilinir ve test edilebilir mimari için en önemli kavramdır.
Sık kullanılan ayırma teknikleri şunlardır:
- Bir uygulamayı Sunum, Alan ve Veri gibi katmanlara ayırın. Bir uygulamayı özellik başına bir modül olacak şekilde de 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ü ile iş mantığını başka bir yere (ör. Composable, ViewModel veya alan katmanı) taşıyın.
- İş mantığı içeren sınıflarda doğrudan çerçeve bağımlılıklarından kaçının. Örneğin, ViewModel'lerde Android bağlamlarını kullanmayın.
- Bağımlılıkları kolayca değiştirin. Örneğin, somut uygulamalar yerine arayüzler kullanın. Bir DI çerçevesi kullanmasanız bile bağımlılık ekleme'yi kullanın.
Sonraki adımlar
Neden test yapmanız gerektiğini ve iki ana test türünü öğrendiğinize göre Neyi test etmeliyim? başlıklı makaleyi okuyabilir veya Test stratejileri hakkında bilgi edinebilirsiniz.
Alternatif olarak, ilk testinizi oluşturmak ve yaparak öğrenmek istiyorsanız Test codelab'lerini inceleyin.