İOS'ta Sahte Verileri Kullanarak Test Etme

Yüksek kaliteli yazılım sağlamak ve regresyondan kaçınmak için, birim testini uygulamak her iOS uygulaması için bir zorunluluktur.
Nesneleri alay etmek, gerçek API'leri kullanarak aynı API'leri kullanarak sahte nesneler yaratan birim testinde kullanılan bir tekniktir.
Bu makalede, iOS uygulamalarında en çok ortaya çıkan senaryolar için sahte verilerin nasıl kullanılacağı ve birim sınamalarının nasıl yazılacağı konusunda size en iyi uygulamaları sunmak için yazılmıştır.

Birim testleri yazarken, daima uygulama hedefinin gerçek verilerini değiştirmekten kaçınmalı ve bunun yerine sahte verileri yalnızca test amacıyla kullanmalıyız.

Aşağıdaki bölümlerde, yaygın olarak kullanılan iOS API'leri için sahte veriler kullanarak testlerin nasıl yazılacağı tartışılacaktır.

Kullanıcı Varsayılanları

Yazılım geliştirmede, Nesnelerin bağımlılıklarını azaltmak her zaman iyi bir uygulamadır. En iyi durumda bağımlılıklar, onları kullanan sınıflara enjekte edilmelidir.

Ancak, gerçek hayattaki iOS Geliştirme senaryolarını kontrol edersek, hemen hemen her proje herhangi bir veriyi depolamak veya almak için doğrudan API'sini çağırarak UserDefaults'u kullanır.

Bu nedenle, API'yı protokollerle soyutlamak yerine UserDefaultsrather test etmek için pratik bir çözüm sunmaya çalışacağız.

UserDefaults üzerinde iki yeni fonksiyon oluşturabiliriz

Uygulama verilerini birim test hedefinden değiştirmemek her zaman iyi bir uygulamadır, bu nedenle test verisi için kullanıcı verilerini kaydetmek için başka bir yer oluşturmalıyız.

Bu durumda, standart UserDefaults'dan tamamen bağımsız olan suiteName - testDefaults içeren yeni bir UserDefaults nesnesi başlatıyoruz.

UserDefaults kullanan basit bir test yazmaya çalışalım

Bu veriler temel olarak yalnızca test için kullanıldığından, bu verileri uygulama dosyalarımızda asılı bırakmaktan kaçınmalıyız, bu nedenle testten sonra bu depolamayı bırakmaktan sorumlu bir işlev yaratırız.

Elbette bu verileri temizlemek için en iyi yer, birim test sınıfımızdaki tearDown işlevi olacaktır.

Singelton Nesneleri

Singletons Nesneleri, pek çok API'de iOS'ta çok kullanılmaktadır, bunları NSFileManager, NSApplication, UIApplication ve diğer birçok yerde bulabiliriz.

Singletonların nasıl test edileceğini bilmek iOS Geliştiricileri için bilinmesi gereken bir şeydir.

Örneğimizde, elmanın iAd çerçevesini kullanacağız. Reklam-atıf ayrıntılarını isteme konusunda gerçek veriler yerine yerel bir JSON yanıtı almak için bir dosya oluşturacağız.

İOS'taki güzel bir özellik, hızlı uzantıların yalnızca önceden tanımlanmış bir API için yeni işlevler eklememize değil, aynı zamanda kendi özel protokollerimize uygun olmalarına izin vermesidir.

Bir AdvertismentClient protokolü tanımlayalım

Ondan sonra, varsayılan ADClient ve aşağıdaki gibi sahte reklam istemcimiz tarafından bu protokole uyarız.

Daha sonra bağımlılığı da değiştiriyoruz

private var adClient: AdvertismentClient = ADClient.shared ()

veya

private var adClient: AdvertismentClient = MockAdClient ()

ve aşağıdaki gibi kullanın

Bu şekilde, gerçek verileri ne zaman kullanacağınıza ve ne zaman test vereceğimize, canlı uygulama hedefimizden API'yi test etmemize veya birim çağırmamıza bağlı olarak kolayca karar verebiliriz.

Temel veri

Çekirdek veriler hala iOS'ta verileri önbelleğe almak için kullanılır. Çekirdek veri varlıklarını test etmek zor olabilir. Aşağıda hem Çekirdek Veri Hizmetlerini hem de Faktoring Verilerini düzenlemenin iyi bir uygulamasını açıklayacağız.

Genelde çoğu durumda, projenin her yerinde çekirdek veri kodunu kullanmak yerine veritabanına belirli verileri almaktan ve yazmaktan sorumlu olan bir hizmet sınıfı oluşturmak her zaman iyi bir şeydir.

Bunun başlıca iki faydası vardır:

  • Gelecekte çekirdek verileri değiştirmek istiyorsanız, yalnızca bir sınıfta değişiklik yapmanız gerekecekse, kullanılan veritabanının sizi ayrıştırır.
  • Bunu yaparak, hangi CoreDataStack'in kullanılacağına ya da başka bir çerçevede ihtiyaç duyabileceğimiz diğer herhangi bir kuruma kolayca karar verebiliriz.

Bir CoreDataStack protokolü oluşturacağız ve bundan sonra bu protokole uyan iki CoreDataStackst, bir MainCoreDataStack ve bir MockCoreDataStack.

Veritabanı Hizmetimiz, uygulama hedefimizde veya Birim Test hedefimizde kullanmamıza bağlı olarak, ikisi tarafından başlatılabilir.

Ana çekirdek veri yığımızın aşağıdaki gibi varsayılan ayarları olacaktır.

Ünite testi her zaman, test ederken mevcut “gerçek” nesnelerin durumunu değiştirmekten kaçınmalıyız.

Bu yüzden, sahte çekirdek veri varlıkları oluşturmak istediğimizde ayrı bir kalıcı depoya sahip olmalı ve bellek içi mağaza tipi yapılandırmasını kullanmalıyız, böylece yapılan değişiklikler diske kaydedilmeyecek ve şu anda kalıcı verilerden tamamen ayrılacaktır.

Şimdi MainCoreDataStack ile varsayılan olarak başlatılan veritabanı hizmetimizi oluşturabileceğiz.

Test sınıfımızda sahte veri yığınıyla başlatabiliriz

Şimdi birkaç basit testi aşağıdaki gibi yazabiliriz:

Bu yaklaşımı kullanarak, uygulama hedefi tarafından depolanan verileri etkilemeden Veritabanı Hizmetimizi kolayca test edebiliriz.

Ağ İstekleri

Ağ Katmanını Test Etirken, protokol oluşturmak ve gerçek Ağ Bağlantısı ve MockNetworkService hem de gerçek veya alaylı servis kullanarak bu bağımlılıkları enjekte etmek için ona uygun bir protokol oluşturmak için yaklaşımı kullanabiliriz.

Bu yazıda, alaycı ve saplamayı daha da iyi idare edecek OHHTTPStubs adında güzel bir açık kaynak kitaplığı kullanacağız.

Bu kütüphane hakkında iyi şey, ünlü iOS ağ kütüphanesi Alamofire ile harika çalışmasıdır.

Stubbing Network isteği OHHTTPStubs ile gerçekten kolaydır, sözlükle özel bir yanıt vererek belirli bir yol veya ana bilgisayar için herhangi bir yanıtı değiştirebilirsiniz.

Bundan sonra, uygulamadan aşağıdaki URL'ye giden her istek, bunun yerine özel yanıtımızı döndürür.

tasksURL = URL (string: “https://jsonplaceholder.typicode.com/todos") izin verin!

Özel tepkiler konusunda gerçekten harika olan şey, hata ve uç durumlarının doğru bir şekilde yanıtlanıp yanıtlanmadığını doğru bir şekilde ele alıp almadığını kolayca test edebilmenizdir.

Sözlüğü yanıt için el ile oluşturmak harika bir özelliktir, ancak birçok özelliğe sahip büyük bir JSON verisini döndürmek istediğimizde, test sınıflarımızda dağınık ve zor bakımı yapılabilir hale gelebilir.

Bu gibi durumlarda, yanıtı aşağıdaki gibi saplamak için bir JSON dosyası kullanabiliriz.

Artık her uygulama isteğimizi gönderdiğinde, dosyalarımıza kaydettiğimiz myResponse.json dosyasındaki yanıtı alacağız.

Bu JSON dosyalarına hassas bilgileri kaydetmekten kaçınmamız gerektiğini hatırlamalıyız çünkü bu dosyaları uygulama ile birlikte gönderirsek kolayca görüntülenebilir.

Daha fazlası için güvenlik konusundaki makalemi kontrol edebilirsiniz.

Sonuç olarak

Birim testi uygulamamız şarttır, mümkün olduğunca regresyondan kaçınmak ve aynı zamanda kusursuz bir uygulama sağlamak istiyoruz.

Bu makalede, iOS Geliştirme sırasında ortaya çıkan yaygın durumlar için nasıl test yapılacağını tartıştık.

UserDefaults, Singeltons, Core Data ve Network Requests testlerinin nasıl yapıldığını tartıştık.

Bu makaleyi beğendiyseniz desteğinizi göstermek için alkışladığınızdan emin olun.

İOS Geliştirici becerilerinizi bir üst düzeye çıkarabilecek daha birçok makaleyi görüntülemek için beni izleyin.

Herhangi bir sorunuz veya yorumunuz varsa, burada bir not bırakmaktan veya arlindaliu.dev@gmail.com adresinden bana e-posta göndermekten çekinmeyin.