Bagaimana Ujian Menggunakan Data Palsu pada iOS

Untuk menyediakan perisian berkualiti tinggi dan mengelakkan regresi, melaksanakan ujian unit adalah satu kemestian untuk setiap aplikasi iOS.
Objek mengejek adalah teknik dalam ujian unit yang mencipta objek palsu dengan menggunakan API yang sama sebagai yang sebenar.
Artikel ini adalah untuk menyediakan anda dengan amalan terbaik tentang cara menggunakan data palsu dan menulis ujian unit untuk sceran yang paling berlaku pada aplikasi iOS.

Apabila menulis ujian unit kami sentiasa harus mengelak daripada mengubah data sebenar sasaran aplikasi dan sebaliknya menggunakan data palsu hanya untuk tujuan ujian.

Bahagian berikut akan membincangkan cara menulis ujian dengan menggunakan data palsu untuk iOS API yang biasa digunakan.

Default Pengguna

Dalam pembangunan Perisian, ia sentiasa merupakan amalan yang baik untuk mengurangkan kebergantungan Objek. Ketergantungan dalam kes terbaik perlu disuntik ke dalam kelas yang menggunakannya.

Tetapi jika kita menyemak senario Pembangunan iOS hidup sebenar hampir setiap projek menggunakan UserDefaults dengan memanggil API itu secara langsung untuk menyimpan atau mengambil semula sebarang data.

Oleh itu, kami akan cuba menawarkan penyelesaian praktikal untuk menguji UserDefaultsrather daripada mengalihkan APInya dengan protokol.

Kita boleh membuat dua fungsi baru di UserDefaults

Ia sentiasa menjadi amalan yang baik untuk tidak mengubah data aplikasi dari sasaran ujian unit, jadi oleh itu kami harus membuat satu lagi tempat menyimpan data pengguna untuk sasaran ujian kami.

Dalam kes ini, kita memulakan objek baru UserDefaults dengan suiteName - testDefaults bahawa ia sepenuhnya bebas daripada standard UserDefaults.

Mari cuba menulis ujian mudah yang menggunakan UserDefaults

Oleh kerana data ini pada dasarnya hanya digunakan untuk ujian, kita harus mengelakkan meninggalkan data yang tergantung di dalam fail permohonan kami, oleh itu, kami membuat fungsi yang bertanggungjawab untuk menjatuhkan penyimpanan ini selepas kami selesai dengan ujian.

Tempat terbaik untuk membersihkan data ini, tentu saja, menjadi fungsi pemedih mata di kelas ujian unit kami.

Objek Singelton

Objek Singletons sangat digunakan pada iOS pada banyak API, kita dapat mencarinya di NSFileManager, NSApplication, UIApplication dan di banyak tempat lain.

Mengetahui bagaimana untuk menguji perseorangan adalah satu perkara yang berguna untuk mengetahui untuk Pemaju iOS.

Dalam contoh kami, kami akan menggunakan rangka kerja iAd epal. Kami akan membuat fail untuk mendapatkan maklum balas JSON tempatan dan bukannya data sebenar untuk meminta butiran pengakuan iklan.

Ciri yang baik dalam iOS ialah sambungan yang pantas membolehkan kita bukan sahaja untuk menambah fungsi baru untuk API yang telah ditetapkan tetapi juga menjadikannya sesuai dengan protokol kustom kita sendiri.

Mari kita tentukan protokol AdvertismentClient

Selepas itu, kami mematuhi protokol ini oleh kedua ADClient lalai dan klien iklan palsu kami seperti berikut

Kami kemudian mengubah kebergantungan sama ada

peribadi var adClient: AdvertismentClient = ADClient.shared ()

atau

peribadi var adClient: AdvertismentClient = MockAdClient ()

dan gunakannya seperti berikut

Dengan cara ini, kita boleh dengan mudah membuat keputusan apabila menggunakan data sebenar dan ketika ujian, bergantung jika kita adalah unit ujian atau memanggil API dari sasaran aplikasi langsung kami.

Data teras

Data teras masih sangat digunakan dalam IOS untuk data caching. Menguji entiti data teras boleh menjadi rumit. Di bawah ini kami akan menerangkan satu amalan yang baik untuk kedua-duanya menganjurkan Perkhidmatan Data Teras dan Data Faking.

Secara umumnya, kebanyakan kes adalah satu perkara yang baik untuk membuat kelas perkhidmatan yang bertanggungjawab dengan mengambil dan menulis data tertentu pada pangkalan data, dan bukannya menggunakan kod data teras di seluruh projek.

Ini mempunyai dua manfaat:

  • Ia menghancurkan anda dari pangkalan data asas yang sedang digunakan, jika anda mahu menggantikan data teras dengan mana-mana pangkalan data lain pada masa akan datang, anda perlu membuat perubahan hanya dalam satu kelas.
  • Dengan melakukan ini, kami dengan mudah boleh memutuskan mana CoreDataStack akan digunakan atau sebarang persediaan lain yang mungkin kita perlukan dalam beberapa kerangka lain.

Kami akan mewujudkan protokol CoreDataStack dan selepas itu dua CoreDataStacksthat mematuhi protokol ini satu MainCoreDataStack dan satu MockCoreDataStack.

DatabaseService kami kemudiannya boleh dimulakan oleh salah satu daripada mereka bergantung kepada jika kami menggunakannya pada sasaran aplikasi kami atau pada sasaran Unit Ujian kami.

Susunan data teras utama kami akan mempunyai tetapan lalai seperti berikut

Apabila ujian Unit sentiasa kita harus mengelakkan mengubah keadaan objek sebenar semasa menguji mereka.

Oleh itu, apabila kita ingin membuat entiti data teras palsu kita harus mempunyai kedai yang berterusan yang berasingan dan menggunakan konfigurasi jenis stor dalam memori supaya perubahan yang dibuat tidak akan disimpan pada cakera dan mereka akan sama sekali terpisah dari data yang masih berterusan.

Kami sekarang akan dapat mencipta perkhidmatan pangkalan data kami yang akan dimulakan secara lalai dengan MainCoreDataStack.

Dan dalam kelas ujian kami, kami boleh memulakannya dengan timbunan data palsu

Kita kini boleh menulis beberapa ujian mudah seperti berikut:

Dengan menggunakan pendekatan ini, kami boleh menguji DatabaseService kami dengan mudah tanpa menjejaskan mana-mana data yang disimpan oleh sasaran aplikasi.

Permintaan Rangkaian

Apabila Ujian Rangkaian Layer kita boleh menggunakan pendekatan berorientasikan protokol untuk membuat protokol dan mematuhinya oleh kedua NetworkService dan MockNetworkService yang sebenar dan selepas itu menyuntik dependencies dengan sama ada menggunakan perkhidmatan yang sebenar atau mengejek.

Dalam artikel ini walaupun kita akan menggunakan perpustakaan sumber terbuka yang sangat baik yang disebut OHHTTPStubs yang akan mengendalikan mengejek dan mengikis lebih baik.

Perkara yang baik tentang perpustakaan ini ialah ia berfungsi dengan baik dengan perpustakaan rangkaian iOS terkenal Alamofire.

Permintaan Rangkaian Stubbing sangat mudah dengan OHHTTPStubs anda boleh menggantikan sebarang tindak balas untuk jalan atau tuan rumah tertentu dengan memberikan respons adat dengan kamus.

Selepas ini, setiap permintaan yang pergi dari apl ke URL berikut akan mengembalikan respons khusus kami.

biarkan tugasURL = URL (rentetan: "https://jsonplaceholder.typicode.com/todos")!

Apa juga yang keren tentang tindak balas tersuai ialah anda boleh menguji dengan mudah jika kesilapan dan kes tepi ditangani dengan betul dengan hanya mengembalikan ralat dalam respon.

Secara manual membina kamus untuk tindak balas adalah ciri yang hebat, tetapi apabila kita mahu memulangkan data JSON yang besar dengan banyak sifat, ia boleh menjadi kemas dan tidak dapat dikekalkan dalam kelas ujian kami.

Dalam kes tersebut, kita boleh menggunakan fail JSON untuk merangsang tindak balas seperti berikut.

Kini setiap kali aplikasi kami menghantar permintaan kami akan mendapat sambutan daripada fail myResponse.json yang kami simpan dalam fail kami.

Kita harus ingat walaupun untuk mengelakkan menyimpan maklumat sensitif dalam fail JSON ini kerana jika kita menghantar fail ini bersama-sama dengan aplikasi mereka dapat dilihat dengan mudah.

Anda boleh menyemak artikel saya mengenai topik keselamatan untuk lebih lanjut.

Kesimpulannya

Unit ujian aplikasi kami adalah satu kemestian jika kita ingin mengelakkan regresi seberapa banyak yang mungkin dan juga cuba menyediakan aplikasi tanpa cacat.

Dalam artikel ini, kami telah membincangkan cara menyediakan ujian untuk kes-kes biasa yang berlaku semasa Pembangunan iOS.

Kami membincangkan cara untuk menguji UserDefaults, Singelons, Data Teras, dan Permintaan Rangkaian.

Jika anda suka artikel ini, pastikan anda bertepuk tangan untuk menunjukkan sokongan anda.

Ikuti saya untuk melihat banyak lagi artikel yang boleh mengambil kemahiran Pemaju iOS anda ke peringkat seterusnya.

Jika anda mempunyai sebarang pertanyaan atau komen, sila bebas untuk meninggalkan nota di sini atau email saya di arlindaliu.dev@gmail.com.