Bir öğe ya da sistem için test stratejisini tasarlarken üç faktör ilgili test unsurları:
- Kapsam: Test, kodun ne kadarına değiniyor? Testler, tek bir yöntemini, uygulamanın tamamını veya arasında bir yerde bulabilirsiniz. İlgili içeriği oluşturmak için kullanılan test edilen kapsamın test ediliyor olması ve bu kapsamın genellikle Konu Altında Test Altındaki Sistem veya Test Altındaki Birimi test edin.
- Hız: Test ne kadar hızlı çalışır? Test hızları milisaniyeden farklı olabilir birkaç dakikaya kadar sürebilir.
- Doğruluk: "Gerçek dünya" nasıldır? ne anlama geliyor? Örneğin, kodun bir bölümü bir ağ isteğinde bulunması gerekiyorsa, test kodu gerçekten yoksa sahte bir sonuçla mı karşılaşıyorsunuz? Test gerçekten bu, kalitenin daha yüksek olduğu anlamına gelir. Bunun karşılığında, testin çalıştırılması daha uzun sürebilir, ağ kapalıysa hatalara neden olabilir veya kullanmak maliyetli olabilir.
Test stratejinizi tanımlamaya nasıl başlayacağınızı öğrenmek için neyi test edeceğinizi öğrenin.
İzolasyon ve bağımlılıklar
Bir element veya öğe sistemini test ederken bunu izole olarak test edersiniz. Örneğin, örnek olarak, ViewModel'i test etmek için bir emülatör başlatmanız ve çünkü Android çerçevesine bağlı değildir (veya bağlı değildir).
Ancak test edilen kişi, testin işe yarayabilmesi için başka kişilere bağlı olabilir. Örneğin, bir ViewModel'in çalışması için bir veri deposuna bağlı olabilir.
Test edilen bir konuya bağımlılık sağlamanız gerektiğinde, bu bir test Double (veya test nesnesi) oluşturmaktır. Test ikilileri, uygulamanızda bileşenler gibi görünseler de belirli bir davranış veya veri sağlıyor. Başlıca avantajları, ve basitleştirir.
İkili test türleri
İkili test türünün çeşitli türleri vardır:
| Sahte | "Çalışan" bir test çifti ancak testler için iyi ama üretime uygun olmayan bir şekilde uygulanmış.
Örnek: Bellek içi veritabanı. Sahteler, alay gerektiren bir yapı gerektirmez ve hafiftir. Bunlar tercih edilir. |
|---|---|
| Dik Yaka | Onu nasıl programladığınızı gösteren ve etkileşimleriyle ilgili beklentileri olan bir test çifti. Etkileşimleri tanımladığınız koşullarla eşleşmiyorsa örnekler, testlerde başarısız olur. Örnekler genellikle tüm bunları başarmak için bir alakalı çerçeveyle oluşturulur.
Örnek: Veritabanındaki bir yöntemin tam olarak bir kez çağrıldığını doğrulayın. |
| Stub | Davranışını programladığınız şekilde davranan ancak etkileşimleriyle ilgili beklentileri olmayan bir test çifti. Genellikle alay gerektiren bir çerçeveyle oluşturulur. Sadelik için saplama yerine sahte öğeler tercih edilir. |
| Dummy | Aktarılan ancak kullanılmayan bir test çifti. Örneğin, yalnızca parametre olarak sağlamanız gerekiyorsa.
Örnek: tıklama geri çağırması olarak iletilen boş bir işlev. |
| Casusluk | Örneklere benzer bazı ek bilgileri de takip eden, gerçek bir nesnenin üzerine yerleştirilen sarmalayıcı. Karmaşıklık eklemek için genellikle bu etiketlerden kaçınılır. Bu nedenle, sahte veya alaylı içerikler casuslara tercih edilir. |
| Gölge | Robolectric'te sahte dosya kullanıldı. |
Sahtekarlık içeren anahtar kelime kullanımı örneği
Bir arayüze bağlı olan bir ViewModel'i birim test etmek istediğinizi varsayalım
UserRepository olarak adlandırılır ve ilk kullanıcının adını bir kullanıcı arayüzüne gösterir. Şunları yapabilirsiniz:
arayüzü uygulayarak ve bilinen sonuçlarını döndürerek sahte bir test oluşturun
verileri.
object FakeUserRepository : UserRepository {
fun getUsers() = listOf(UserAlice, UserBob)
}
val const UserAlice = User("Alice")
val const UserBob = User("Bob")
Bu sahte UserRepository öğesinin, yerel ve uzak verilere bağlı olmasına gerek yoktur
kaynak oluşturacaktır. Dosya test kaynağında bulunuyor
ayarlanır ve üretim uygulamasıyla birlikte gönderilmez.
Aşağıdaki test, ViewModel'in ilk kullanıcıyı doğru şekilde ortaya çıkardığını doğrular adını da ekleyebilirsiniz.
@Test
fun viewModelA_loadsUsers_showsFirstUser() {
// Given a VM using fake data
val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init
// Verify that the exposed data is correct
assertEquals(viewModel.firstUserName, UserAlice.name)
}
Bir birim testinde UserRepository değerini sahte ile değiştirmek kolaydır, çünkü
ViewModel, test kullanıcısı tarafından oluşturulur. Ancak, zaman çizelgesini
rastgele elemanları kullanır.
Bileşenleri ve bağımlılık yerleştirmeyi değiştirme
Testlerin, test edilen sistemlerin oluşturulması üzerinde herhangi bir kontrolü olmadığında test çiftleri için bileşenlerin değiştirilmesi daha karmaşık hale gelir ve uygulamanızın mimarisinin test edilebilir bir tasarıma sahip olmasını sağlayın.
Büyük uçtan uca testler bile test ikililerini kullanmaktan yararlanabilir (örneğin, uygulamanızda tüm kullanıcı işlemleri akışında gezinen araçlı kullanıcı arayüzü testi. İçinde bu durumda testinizi hermetik hale getirebilirsiniz. Hermetik test, internetten veri getirmek gibi tüm dış bağımlılıkları belirlemenize yardımcı olur. Bu güvenilirliği ve performansı artırır.
Uygulamanızı bu esnekliği manuel olarak sağlayacak şekilde tasarlayabilirsiniz. Ancak bunu bileşenleri değiştirmek için Hilt gibi bir bağımlılık yerleştirme çerçevesi kullanma test sırasında uygulamanızda görüntülenebilir. Hilt test kılavuzuna bakın.
Robolektrik
Android'de Robolectric çerçevesini kullanabilirsiniz. özel bir test çifti türü sağlar. Robolectric, testlerinizi şurada çalıştırmanıza olanak tanır: veya sürekli entegrasyon ortamınızda sakıncası yoktur. Bir olmadan, emülatör veya cihaz olmadan normal JVM'ye bağlanabilirsiniz. İzlenme sayısındaki artışın, kaynak yükleme ve Android çerçevesinin diğer bölümleri için test gölgeler olarak adlandırılır.
Robolectric bir simülatör olduğundan basit birim testlerinin yerine geçmemeli veya uyumluluk testi yapması gerekiyor. Hız sağlar ve maliyetleri düşürür bazı durumlarda kalitenin düşük olduğu söylenir. Kullanıcı arayüzü testleri için iyi bir yaklaşım, hem Robolectric hem de enstrümanlı testlerle uyumludur ve ne zaman çalıştırılacağına gerekliliklere bağlı olarak değişebilir. Her iki Espresso Compose testleri de Robolectric'te çalıştırılabilir.