Bu sayfada, Android uygulamalarını test etmenin temel ilkeleri, merkezi en iyi uygulamalar ve bunların faydaları özetlenmektedir.
Testin avantajları
Testler, uygulama geliştirme sürecinin ayrılmaz bir parçasıdır. Uygulamanız için tutarlı bir şekilde testler çalıştırarak uygulamanızı herkese açık bir şekilde yayınlamadan önce doğruluğunu, işlevsel davranışını ve kullanılabilirliğini doğrulayabilirsiniz.
Uygulamada 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 veya 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çırmak kolay olabilir. Otomatik test, sizin için testleri gerçekleştiren ve daha hızlı olan, daha fazla tekrarlanabilir ve genellikle geliştirme sürecinin başlarında uygulamanızla ilgili daha uygulanabilir geri bildirimler sağlayan araçların kullanılmasını içerir.
Android'deki test türleri
Mobil uygulamalar karmaşıktır ve birçok ortamda iyi bir şekilde çalışmalıdı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: Hızlı ve etkili bir şekilde yapılıyor mu?
- Erişilebilirlik testi: Erişilebilirlik hizmetleriyle iyi çalışıyor mu?
- Uyumluluk testi: Her cihaz ve API düzeyinde iyi çalışıyor mu?
Kapsam
Testler boyut 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 uygulamanın tüm ekran veya kullanıcı akışı gibi daha büyük bölümlerini doğrular.
- Orta düzeyde testler devam eder ve iki veya daha fazla birim arasındaki entegrasyonu kontrol edin.
Testleri sınıflandırmanın birçok yolu vardır. Ancak, uygulama geliştiriciler için en önemli fark testlerin yapıldığı yerdir.
Enstrümanlı ve yerel testler
Testleri bir Android cihazda veya başka bir bilgisayarda çalıştırabilirsiniz:
- Araçlı testler bir Android cihazda fiziksel veya emüle edilmiş olarak çalıştırılır. Uygulama, komut ekleyen ve durumu okuyan bir test uygulamasıyla birlikte oluşturulup yüklenir. Araçlı testler genellikle kullanıcı arayüzü testleridir, bir uygulamayı başlatma ve ardından uygulamayla etkileşim kurmadır.
- Yerel testler, geliştirme makinenizde veya bir sunucuda yürütüldüğünden ana makine tarafı testleri olarak da adlandırılır. Genellikle küçük ve hızlı olan bu uygulamalar, test edilen konuyu uygulamanın geri kalanından ayırır.
Bazı 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 donanımlı 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ü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()))
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 için birim testinin bir bölümünü gösterir (yerel, ana makine tarafı test):
// 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ı 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 testleri, emüle edilmiş cihazlarda veya fiziksel cihazın kendisinde yapılır. Yerel iş istasyonunuzun JVM'sinde daha düşük doğruluk testleri çalıştırı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 değildir.
Güvenilir olmayan testler
Doğru tasarlanmış ve uygulanmış test çalıştırmalarında bile hatalar meydana gelir. Örneğin, gerçek bir cihazda test çalıştırırken, testin ortasında otomatik güncelleme başlayıp başarısız olmasına neden olabilir. Kodunuzdaki hafif yarış koşulları, zamanın yalnızca küçük bir yüzdesinde meydana gelebilir. Sürenin% 100'ünü geçemeyen testler kesintisizdir.
Test edilebilir mimari
Test edilebilir bir uygulama mimarisiyle kod, farklı bölümlerini ayrı ayrı 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 aşağıdakileri üretir:
- Daha büyük, daha yavaş, daha stabil olmayan testler. Birim testi yapılamayan sınıfların, daha büyük entegrasyon testlerinin veya kullanıcı arayüzü testlerinin kapsamına girmesi 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 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.
Ayrıştırma yaklaşımları
Bir işlevin, sınıfın veya modülün bir kısmını diğerlerinden ayırabilirseniz bunu test etmek daha kolay ve etkili olur. Bu uygulamaya ayırma denir ve test edilebilir mimari için en önemli kavramdır.
Yaygın ayrıştı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ü ve iş mantığını Composable, ViewModel veya alan adı katmanı gibi başka yerlere 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ıların 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 yerleştirme'yi kullanın.
Sonraki adımlar
Neden test etmeniz gerektiğini ve iki ana test türünü öğrendiğinize göre Neyi test etmelisiniz? bölümünü okuyabilirsiniz.
Alternatif olarak, ilk testinizi oluşturup uygulayarak öğrenmek istiyorsanız Codelab'leri test etme sayfasına göz atın.