Kami sedang menulis kasus uji unit di proyek kami. Implementasi untuk metode basis data ada dan berfungsi dengan baik. Dalam hal ini mengapa kita perlu menulis objek tiruan? Apakah ada alasan khusus? Mengapa saya tidak bisa menguji penerapan DAO secara langsung?
Jawaban:
Anda tidak boleh mengejek panggilan ke database karena itu akan mengalahkan tujuan. Apa yang Anda HARUS mengejek, misalnya, panggilan ke DAO Anda dari, katakanlah, lapisan layanan. Mengejek memungkinkan Anda untuk menguji metode secara terpisah.
Katakanlah Anda memiliki simulasi restoran dengan arsitektur seperti ini:
Cook <=> Server <=> Customer
Anda ingin menguji setiap lapisan secara independen. Inilah Serverlayer layanan Anda dan Cookdapat dianggap sebagai DAO. Ini Serveradalah apa yang ingin Anda tiru saat pengujian Customer, dan Cookapa yang ingin Anda tiru saat menguji Server. Namun, Cookunit ini harus memverifikasi bahwa implementasinya mengembalikan hamburger ketika hamburger dipesan dan bukan ban karet.
Sangatlah baik untuk menguji businesslogic bersama dengan database. tetapi tes ini disebut tes integrasi bahkan jika Anda menggunakan nunit atau junit atau phpunit untuk menjalankan ini.
Unittests adalah tes spezialized di mana pengujian dalam isolasi (mis. Buisinesslogic tanpa database) adalah penting. Mock / fakes / stup digunakan untuk menegakkan isolasi ini.
Cukup: untuk menguji DAO aktual dan bukan konten basis data.
Misalkan kelas DAO Person Anda memiliki metode getByName (). Anda menulis tes dan memanggil Person.getByName ("John Smith"). Misalkan tes gagal, karena seseorang menghapus catatan John dari database. Sekarang, setiap perangkat lunak CI dan penyelia / pengulas Anda dapat mengklaim bahwa perangkat lunak Anda salah, padahal kenyataannya tidak. Jika Anda mengejek DB, Anda dapat membuktikan bahwa DAO Anda berfungsi jika diberikan baris yang benar dari tabel yang benar.
Jika Anda benar-benar ingin menguji database itu sendiri, yaitu: jika eksekusi metode DAO tertentu menempatkan data dalam keadaan tertentu, maka itu juga mungkin. Terlebih lagi itu sangat membantu dengan model data yang aneh (EAV, set pohon bersarang) di mana Anda tidak bisa mengharapkan database untuk memberikan integritas anti peluru. Lihatlah DBUnit untuk membuat hidup Anda lebih mudah.
Alasan lain adalah untuk menghindari waktu pelaksanaan sebenarnya menjalankan perintah database. Ini mungkin tidak terlihat seperti banyak tetapi overhead pengaturan dan penghancuran koneksi pada akhirnya akan bertambah dan kemungkinan besar secara signifikan meningkatkan waktu keseluruhan untuk menjalankan test suite dibandingkan dengan menggunakan benda tiruan.
Untuk mengisolasi kelas yang Anda uji. Atau jika tes gagal bagaimana Anda tahu masalahnya ada di kelas yang Anda uji atau salah satu dari dependensinya.