Apa yang harus saya tiru dalam tes aplikasi dengan tingkat layanan dan tingkat DAO?

8

Kelas saya mengikuti struktur ini

Tingkat Layanan (membuat dan memetakan InputDTO ke Data DB)
DAO Tier (sebenarnya mengeksekusi panggilan DB)

Ketika saya menulis tes tingkat layanan JUnit, tingkat DAO dipanggil, dan ini mengharapkan koneksi DB yang sebenarnya dan mendapatkan data dari DB.

Haruskah saya mengejek tingkat DAO sepenuhnya dari tingkat layanan, atau haruskah saya mengejek koneksi DB dan data yang diterima dari DB?

Kedua, aplikasi mengharapkan data tertentu dari cache.

Untuk waktu menjalankan JUnit, tidak ada cache, jadi bagaimana ini harus ditangani? Metode tingkat layanan termasuk mencari cache untuk mendapatkan detailnya.

— shinynewbike
sumber

9

Saya akan berbicara tentang Uji Ganda, jika Anda belum menemukan istilah ini maka Anda mungkin akan ingin membaca tautan artikel Martin Fowler terlebih dahulu.

Untuk pengujian Database - Jika Anda mengikuti murni pendekatan Unit pengujian maka Anda akan menggunakan Stub atau Mock jenis Uji dua kali untuk mengejek keluar koneksi DB dan tanggapan nya. Jika Anda menggunakan Mock maka saya akan merekomendasikan menggunakan Mockito, JMock atau alat mengejek favorit Anda lainnya. Namun, ini cukup melelahkan dalam hal menguji sumber daya pihak ketiga yang besar seperti database.
Untuk pengujian Basis Data - Jika Anda mengikuti definisi yang lebih longgar tentang pengujian unit, maka Anda dapat menggunakan Uji Ganda Palsu . Dalam kasus khusus Anda, ini akan menjadi basis data dalam memori seperti HSQL. Ini adalah cara yang sangat populer untuk 'unit' menguji lapisan basis data Anda. Beberapa akan berpendapat bahwa ini bukan pengujian unit, dan itu adalah pengujian integrasi sebagai gantinya. Saya pikir itu sebenarnya OK - faktanya adalah, Anda memiliki beberapa tes yang mengeluarkan kode Anda :-)
Untuk pengujian cache - Gaya rintisan dari Test Double kemungkinan menjadi teman Anda di sini - tergantung pada seberapa kompleks API cache tersebut.

HTH!

— Martijn Verburg
sumber

3

Jawaban yang bagus, ide kami adalah pendekatan pengujian unit murni - berusaha untuk tidak membuat tes integrasi besar tetapi tes unit lebih kecil Saya tidak mengetahui istilah Uji Ganda, terima kasih

— shinynewbike

2

+1 selalu mendukung cara terkecil, paling sederhana untuk menggunakan kode spesifik yang Anda gunakan. Ketika sistem tumbuh memperkenalkan tes integrasi / fungsional / sistem untuk bertindak sebagai indikator gagal cepat.

— Gary Rowe

1

+1 Untuk menyebut Mockito. Sejauh ini, ini merupakan kerangka kerja mengejek yang paling intuitif yang pernah saya gunakan dalam bahasa apa pun, dan bahkan memiliki fitur bagus yang mengurangi rasa sakit karena dipaksa secara retroaktif dalam pengujian unit ke kode warisan yang awalnya tidak pernah dirancang dengan tes unit dalam pikiran. Objek Mockito Spy sangat berguna untuk ini.

— maple_shaft

Istilah "unit test" saat ini paling umum digunakan untuk menggambarkan karakteristik teknis dari suatu tes: tes unit adalah tes yang berjalan cepat dan tanpa prasyarat. Istilah "tes integrasi", bila digunakan dengan benar, menjelaskan tujuan pengujian: untuk menguji integrasi bagian-bagian. Jadi "unit test" dapat dengan mudah menjadi "tes integrasi" jika menguji beberapa integrasi dan berjalan cepat.

— Oberlies

2

Secara abstrak jawabannya cukup sederhana.

Anda memiliki tiga lapisan.

[Kasus tes] -> [Perilaku yang diuji] -> [Kolaborator digunakan oleh perilaku itu]

Lapisan ketiga inilah yang harus diejek. Sebagai contoh:

itu PokemonCaptureServiceTest;
tes PokemonCaptureService;
yang menggunakan Pokeball

Dalam contoh ini ternyata itu Pokeballadalah logika pihak ketiga. Ini membutuhkan semua jenis pipa seperti koneksi database dan file properti dll. Anda percaya pihak ketiga Anda telah mengujinya dengan tepat, jadi Anda ingin menghilangkannya dari pengujian Anda PokemonCaptureService. Karena itu harus diejek.

Namun, di waktu dan tempat lain, kolaborator Pokeballadalah kelas sederhana yang memperkenalkan sangat sedikit kerumitan ke dalam kasus uji dan dapat dimasukkan dalam tes dengan mudah. Dalam hal ini Anda mungkin memutuskan untuk memasukkan contoh nyata Pokeballdalam PokemonCaptureServicecontoh yang diuji.

Tidak ada aturan yang keras dan cepat. Terserah Anda untuk merancang tes Anda dengan cara yang tampaknya terbaik bagi Anda. Tujuan Anda adalah untuk membuat tes yang benar dan dapat dipertahankan secepat mungkin. Pengalaman adalah kunci di sini. Tulis lebih banyak tes & Anda akan segera mendapatkan intuisi yang bagus untuk itu.

— Synesso
sumber

0

Sulit untuk mengatakan apa sebenarnya yang ingin Anda uji karena menilai dari pertanyaan Anda ada di mana-mana. Jadi sulit untuk memberi Anda contoh praktis tentang cara melanjutkan selain mengarahkan Anda ke artikel tentang cara mengejek barang. Jadi, Anda harus lebih spesifik dan sedikit membagi:

Apakah Anda ingin menguji agar cache berfungsi dengan baik?
Apakah Anda ingin menguji beberapa panggilan DB khususnya?
Apakah Anda ingin menguji aplikasi sehingga menggunakan cache dengan benar?

Setelah Anda memutuskan dengan tepat apa unit yang ingin Anda uji, kemudian memilih apa yang akan diejek menjadi mudah: dalam tes unit murni, segala sesuatu kecuali "unit yang diuji" harus diejek. Alasan di balik ini adalah bahwa Anda dapat yakin dari harapan set up Anda pada mengejek bahwa unit yang diuji bekerja sebagaimana mestinya.

Selain itu, Anda mungkin ingin menulis beberapa tes dalam JUnit yang merupakan tes integrasi, yaitu menggunakan lebih sedikit mengejek. Bahkan jika mereka digunakan sebagai pemeriksaan kewarasan untuk melihat apakah desain perangkat lunak sudah benar, Anda harus menyadari bahwa mereka akan rapuh dan tidak akan selalu memberikan indikator apa pun tentang apa yang sebenarnya salah dengan aplikasi atau sistem Anda.

— Spoike
sumber