Cara Menguji Menggunakan Data Palsu di iOS

Untuk menyediakan perangkat lunak berkualitas tinggi dan menghindari regresi, penerapan pengujian unit adalah suatu keharusan untuk setiap aplikasi iOS.
Mengejek objek adalah teknik dalam pengujian unit yang membuat objek palsu dengan menggunakan API yang sama dengan yang asli.
Artikel ini akan memberi Anda praktik terbaik tentang cara menggunakan data palsu dan menulis tes unit untuk skenario paling banyak terjadi pada aplikasi iOS.

Saat menulis unit-test kita harus selalu menghindari mengubah data nyata dari target aplikasi dan alih-alih menggunakan data palsu hanya untuk tujuan pengujian.

Bagian berikut akan membahas cara menulis tes dengan menggunakan data palsu untuk iOS API-s yang umum digunakan.

Default Pengguna

Dalam pengembangan perangkat lunak, selalu merupakan praktik yang baik untuk mengurangi ketergantungan Objek. Ketergantungan dalam kasus terbaik harus disuntikkan ke dalam kelas yang menggunakannya.

Tetapi jika kita memeriksa skenario Pengembangan iOS kehidupan nyata, hampir setiap proyek menggunakan UserDefaults dengan memanggilnya API secara langsung untuk menyimpan atau mengambil data apa pun.

Oleh karena itu kami akan mencoba menawarkan solusi praktis untuk menguji UserDefaultsrather daripada mengabstraksikan API-nya dengan protokol.

Kami dapat membuat dua fungsi baru di UserDefaults

Itu selalu merupakan praktik yang baik untuk tidak mengubah data aplikasi dari target pengujian unit, oleh karena itu kita harus membuat tempat lain untuk menyimpan data pengguna untuk target pengujian kami.

Dalam hal ini, kami menginisialisasi objek baru UserDefaults dengan suiteName - testDefaults yang sepenuhnya independen dari UserDefaults standar.

Mari kita coba menulis tes sederhana yang menggunakan UserDefaults

Karena data ini pada dasarnya hanya digunakan untuk pengujian kami harus menghindari meninggalkan data yang tergantung pada file aplikasi kami, oleh karena itu, kami membuat fungsi yang bertanggung jawab untuk menjatuhkan penyimpanan ini setelah kami selesai dengan tes.

Tempat terbaik untuk membersihkan data ini, tentu saja, adalah fungsi tearDown di kelas pengujian unit kami.

Singelton Objects

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

Mengetahui cara menguji lajang adalah hal yang berguna untuk diketahui bagi Pengembang iOS.

Dalam contoh kita, kita akan menggunakan kerangka kerja iAd dari apple. Kami akan membuat file untuk mendapatkan respons JSON lokal alih-alih data nyata tentang meminta detail atribusi iklan.

Fitur bagus di iOS adalah ekstensi dalam swift memungkinkan kami tidak hanya menambahkan fungsi baru untuk API yang telah ditentukan, tetapi juga membuatnya sesuai dengan protokol khusus kami sendiri.

Mari kita definisikan protokol AdvertismentClient

Setelah itu, kami mematuhi protokol ini oleh ADClient default dan klien iklan palsu kami seperti berikut

Kami kemudian mengubah ketergantungan ke keduanya

private var adClient: AdvertismentClient = ADClient. Shared ()

atau

private var adClient: AdvertismentClient = MockAdClient ()

dan gunakan sebagai berikut

Dengan cara ini, kita dapat dengan mudah memutuskan kapan akan menggunakan data nyata dan kapan pengujian, tergantung jika kita menguji unit atau memanggil API dari target aplikasi langsung kita.

Data inti

Data inti masih sangat digunakan di iOS untuk caching data. Menguji entitas data inti bisa rumit. Di bawah ini kami akan menjelaskan praktik yang baik dalam mengatur Layanan Data Inti dan Memalsukan Data.

Secara umum dalam sebagian besar kasus selalu merupakan hal yang baik untuk membuat kelas layanan yang bertanggung jawab dengan mengambil dan menulis data spesifik pada database, daripada menggunakan kode data inti di seluruh proyek.

Ini terutama memiliki dua manfaat:

  • Ini memisahkan Anda dari basis data mendasar yang sedang digunakan, jika Anda ingin mengganti data inti dengan basis data lain di masa mendatang, Anda harus membuat perubahan hanya dalam satu kelas.
  • Dengan melakukan ini, kita dapat dengan mudah memutuskan CoreDataStack mana yang akan digunakan atau pengaturan lain yang mungkin kita perlukan dalam beberapa kerangka kerja lain.

Kami akan membuat protokol CoreDataStack dan setelah itu dua CoreDataStacksthat sesuai dengan protokol ini satu MainCoreDataStack dan satu MockCoreDataStack.

Layanan Database kami kemudian dapat diinisialisasi oleh salah satu dari mereka tergantung pada apakah kami menggunakannya pada target aplikasi kami atau pada target Pengujian Unit kami.

Tumpukan data inti utama kami akan memiliki pengaturan default seperti berikut

Ketika pengujian Unit selalu kita harus menghindari mengubah keadaan objek 'nyata' saat mengujinya.

Jadi ketika kita ingin membuat entitas data inti palsu, kita harus memiliki toko persisten terpisah dan menggunakan konfigurasi tipe toko dalam-memori sehingga perubahan yang dilakukan tidak akan disimpan di disk dan mereka akan sepenuhnya terpisah dari data yang saat ini masih ada.

Kami sekarang akan dapat membuat layanan database kami yang diinisialisasi secara default dengan MainCoreDataStack.

Dan di kelas pengujian kami, kami dapat menginisialisasi dengan tumpukan data palsu

Kami sekarang dapat menulis beberapa tes sederhana sebagai berikut:

Dengan menggunakan pendekatan ini, kita dapat dengan mudah menguji Layanan Database tanpa memengaruhi data yang disimpan oleh target aplikasi.

Permintaan Jaringan

Saat Menguji Lapisan Jaringan, kita dapat menggunakan pendekatan berorientasi protokol untuk membuat protokol dan menyesuaikannya dengan NetworkService dan MockNetworkService yang nyata dan setelah itu menyuntikkan dependensi dengan menggunakan layanan nyata atau mengejek.

Pada artikel ini kita akan menggunakan pustaka open-source yang sangat bagus yang disebut OHHTTPStubs yang akan menangani ejekan dan stubbing dengan lebih baik.

Hal yang baik tentang perpustakaan ini adalah ia bekerja sangat baik dengan perpustakaan jaringan iOS yang terkenal Alamofire.

Permintaan Stubbing Network sangat mudah dengan OHHTTPStubs Anda dapat mengganti respons untuk jalur atau host tertentu dengan memberikan respons khusus dengan kamus.

Setelah ini, setiap permintaan dari aplikasi ke URL berikut akan mengembalikan respons khusus kami.

biarkan taskURL = URL (string: “https://jsonplaceholder.typicode.com/todos")!

Yang juga sangat keren tentang tanggapan khusus adalah Anda dapat dengan mudah menguji apakah kasus kesalahan dan tepi ditangani dengan benar dengan hanya mengembalikan kesalahan dalam respons.

Secara manual membangun kamus untuk respons adalah fitur yang hebat, tetapi ketika kami ingin mengembalikan data JSON yang besar dengan banyak properti dapat menjadi berantakan dan sulit dipertahankan di kelas pengujian kami.

Dalam kasus tersebut, kita dapat menggunakan file JSON untuk mematikan respons seperti berikut.

Sekarang setiap kali aplikasi kami mengirimkan permintaan, kami akan mendapatkan respons dari file myResponse.json yang kami simpan di file kami.

Namun kita harus ingat untuk menghindari penyimpanan informasi sensitif dalam file JSON ini karena jika kita mengirim file-file ini bersama-sama dengan aplikasi mereka dapat dilihat dengan mudah.

Anda dapat memeriksa artikel saya tentang topik keamanan untuk lebih.

Kesimpulannya

Unit menguji aplikasi kita adalah suatu keharusan jika kita ingin menghindari regresi sebanyak mungkin dan juga mencoba untuk menyediakan aplikasi tanpa cacat.

Dalam artikel ini, kami telah membahas cara menyediakan pengujian untuk kasus umum yang terjadi selama Pengembangan iOS.

Kami membahas cara menguji UserDefaults, Singeltons, Data Inti, dan Permintaan Jaringan.

Jika Anda menyukai artikel ini, pastikan untuk bertepuk tangan untuk menunjukkan dukungan Anda.

Ikuti saya untuk melihat lebih banyak artikel yang dapat meningkatkan keterampilan Pengembang iOS Anda ke tingkat selanjutnya.

Jika Anda memiliki pertanyaan atau komentar, jangan ragu untuk meninggalkan catatan di sini atau mengirim email kepada saya di arlindaliu.dev@gmail.com.