Jawaban lain menjelaskan apa itu mengejek. Biarkan saya membimbing Anda melaluinya dengan berbagai contoh . Dan percayalah, ini sebenarnya jauh lebih sederhana daripada yang Anda pikirkan.
tl; dr Ini adalah instance dari kelas asli. Ini memiliki data lain yang disuntikkan ke dalam sehingga Anda menghindari pengujian bagian yang disuntikkan dan hanya fokus pada pengujian rincian implementasi kelas / fungsi Anda.
Contoh sederhana:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Seperti yang Anda lihat, saya tidak menguji LineA yaitu saya tidak memvalidasi parameter input. Saya tidak memvalidasi untuk melihat apakah num1, num2 adalah Integer. Saya tidak menegaskan hal itu.
Saya hanya menguji untuk melihat apakah LineB ( implementasi saya ) memberikan nilai-nilai yang diejek 1dan 5melakukan seperti yang saya harapkan.
Jelas dalam kata sebenarnya ini bisa menjadi jauh lebih kompleks. Parameter bisa berupa objek kustom seperti Orang, Alamat, atau detail implementasi bisa lebih dari satu +. Tetapi logika pengujian akan sama.
Contoh Non-coding:
Asumsikan Anda sedang membangun mesin yang mengidentifikasi jenis dan merek perangkat elektronik untuk keamanan bandara. Mesin melakukan ini dengan memproses apa yang dilihatnya dengan kameranya.
Sekarang manajer Anda berjalan di pintu dan meminta Anda untuk mengujinya.
Maka Anda sebagai pengembang Anda dapat membawa 1000 objek nyata, seperti MacBook pro, Google Nexus, pisang, iPad dll di depannya dan uji dan lihat apakah semuanya bekerja.
Tetapi Anda juga dapat menggunakan benda - benda yang diejek , seperti MacBook pro yang identik (tanpa bagian internal yang nyata) atau pisang plastik di depannya. Anda dapat menyelamatkan diri dari investasi dalam 1000 laptop nyata dan pisang busuk.
Intinya adalah Anda tidak mencoba menguji apakah pisang itu palsu atau tidak. Juga tidak menguji apakah laptop itu palsu atau tidak. Semua yang Anda lakukan adalah pengujian jika mesin Anda setelah melihat pisang itu akan mengatakan not an electronic devicedan untuk MacBook Pro itu akan berkata: Laptop, Apple. Untuk mesin, hasil deteksi harus sama untuk elektronik palsu / diejek dan elektronik nyata
Logika yang disebutkan di atas berlaku untuk pengujian unit kode aktual juga. Itu adalah fungsi yang harus bekerja sama dengan nilai nyata yang Anda dapatkan dari input nyata (dan interaksi) atau diejeknilai yang Anda berikan selama pengujian unit. Dan sama seperti bagaimana Anda menyelamatkan diri dari menggunakan pisang nyata atau MacBook, dengan unit-test (dan mengejek) Anda menyelamatkan diri dari keharusan melakukan sesuatu yang menyebabkan server Anda mengembalikan kode status 500, 403, 200, dll. (Memaksa server Anda untuk memicu 500 hanya ketika server turun, sedangkan 200 adalah ketika server naik. Semakin sulit untuk menjalankan 100 tes fokus jaringan jika Anda harus terus-menerus menunggu 10 detik antara beralih dari server ke atas dan ke bawah). Jadi alih-alih Anda menyuntikkan / mengejek respons dengan kode status 500, 200, 403, dll dan menguji unit / fungsi Anda dengan nilai yang disuntikkan / diejek.
Contoh Pengodean:
Katakanlah Anda sedang menulis aplikasi iOS dan memiliki panggilan jaringan. Tugas Anda adalah menguji aplikasi Anda . Untuk menguji / mengidentifikasi apakah panggilan jaringan berfungsi seperti yang diharapkan BUKAN TANGGUNG JAWAB ANDA. Adalah tanggung jawab (tim server) pihak lain untuk mengujinya. Anda harus menghapus ketergantungan (jaringan) ini dan masih terus menguji semua kode Anda yang berfungsi di sekitarnya.
Panggilan jaringan dapat mengembalikan kode status berbeda 404, 500, 200, 303, dll dengan respons JSON.
Aplikasi Anda seharusnya berfungsi untuk semuanya (jika terjadi kesalahan, aplikasi Anda harus membuang kesalahan yang diharapkan). Apa yang Anda lakukan dengan mengejek adalah Anda membuat respons jaringan 'imajiner — mirip dengan respons nyata' (seperti 200 kode dengan file JSON) dan menguji kode Anda tanpa 'membuat panggilan jaringan nyata dan menunggu respons jaringan Anda'. Anda secara manual mengubah kode / mengembalikan respons jaringan untuk SEMUA jenis respons jaringan dan melihat apakah aplikasi Anda berfungsi seperti yang Anda harapkan. (Anda tidak pernah berasumsi / menguji 200 dengan data yang salah, karena itu bukan tanggung jawab Anda, tanggung jawab Anda adalah menguji aplikasi Anda dengan 200 yang benar, atau dalam kasus 400, 500, Anda menguji apakah aplikasi Anda melakukan kesalahan yang tepat)
Imajinasi yang menciptakan ini - mirip dengan yang nyata dikenal sebagai mengejek.
Untuk melakukan ini, Anda tidak dapat menggunakan kode asli Anda (kode asli Anda tidak memiliki tanggapan yang dimasukkan sebelumnya, kan?). Anda harus menambahkan sesuatu ke dalamnya, menyuntikkan / memasukkan data tiruan yang biasanya tidak diperlukan (atau bagian dari kelas Anda).
Jadi, Anda membuat instance kelas asli dan menambahkan apa pun (di sini adalah HTTPResponse jaringan, data ATAU dalam hal kegagalan, Anda melewati errorString yang benar, HTTPResponse) yang Anda butuhkan untuk itu dan kemudian menguji kelas yang diejek .
Singkatnya, mengejek adalah untuk menyederhanakan dan membatasi apa yang Anda uji dan juga membuat Anda memberi makan apa yang bergantung pada kelas. Dalam contoh ini Anda menghindari pengujian yang jaringan menyebut diri mereka sendiri , dan bukan uji apakah aplikasi Anda bekerja seperti yang Anda harapkan dengan disuntikkan output / tanggapan - oleh mengejek kelas
Tidak perlu dikatakan, Anda menguji setiap respons jaringan secara terpisah.
Sekarang pertanyaan yang selalu saya pikirkan adalah: Kontrak / titik akhir dan pada dasarnya respon JSON dari API saya diperbarui secara konstan. Bagaimana saya bisa menulis unit test yang mempertimbangkan ini?
Untuk menguraikan lebih lanjut tentang ini: katakanlah model membutuhkan kunci / bidang bernama username. Anda menguji ini dan tes Anda lulus. 2 minggu kemudian backend mengubah nama kunci menjadi id. Tes Anda masih berlalu. Baik? atau tidak?
Apakah itu tanggung jawab pengembang backend untuk memperbarui ejekan. Haruskah itu menjadi bagian dari perjanjian kami bahwa mereka memberikan cemoohan yang diperbarui?
Jawaban untuk masalah di atas adalah bahwa: unit test + proses pengembangan Anda sebagai pengembang sisi klien harus / akan menangkap respons yang sudah ketinggalan zaman. Jika Anda bertanya kepada saya bagaimana caranya? baik jawabannya adalah:
Aplikasi kami yang sebenarnya akan gagal (atau tidak gagal namun tidak memiliki perilaku yang diinginkan) tanpa menggunakan API yang diperbarui ... maka jika itu gagal ... kami akan membuat perubahan pada kode pengembangan kami. Yang lagi-lagi menyebabkan pengujian kami gagal .... yang harus kami perbaiki. (Sebenarnya jika kita ingin melakukan proses TDD dengan benar kita tidak boleh menulis kode apa pun tentang bidang kecuali kita menulis tes untuk itu ... dan melihatnya gagal dan kemudian pergi dan tulis kode pengembangan yang sebenarnya untuk itu.)
Ini semua berarti bahwa backend tidak harus mengatakan: "hei kita perbarui tiruan" ... itu akhirnya terjadi melalui pengembangan kode / debugging Anda. ّ Karena itu semua adalah bagian dari proses pengembangan! Meskipun jika backend memberikan respons yang mengejek untuk Anda maka itu lebih mudah.
Seluruh poin saya dalam hal ini adalah bahwa (jika Anda tidak dapat secara otomatis mendapatkan tanggapan API yang diolok-olok yang diperbarui) beberapa interaksi manusia diperlukan, yaitu pembaruan JSON secara manual dan mengadakan pertemuan singkat untuk memastikan nilainya diperbarui akan menjadi bagian dari proses Anda
Bagian ini ditulis berkat diskusi kendur dalam kelompok pertemuan CocoaHead kami
Hanya untuk iOS devs:
Contoh yang sangat baik dari mengejek adalah pembicaraan Praktis-Berorientasi Protokol oleh Natasha Muraschev . Langsung saja ke menit 18:30, meskipun slide mungkin tidak sinkron dengan video yang sebenarnya 🤷♂️
Saya sangat suka bagian ini dari transkrip:
Karena ini adalah pengujian ... kami ingin memastikan bahwa getfungsi dari Gettabledipanggil, karena dapat kembali dan fungsinya secara teoritis dapat menetapkan berbagai item makanan dari mana saja . Kita perlu memastikan bahwa itu disebut;