Database dan Pengujian Unit / Integrasi

Saya telah berdiskusi dengan seseorang tentang pengujian unit / integrasi dengan aplikasi web dan saya memiliki ketidaksepakatan tentang ide inti. Masalahnya adalah orang yang saya ajak bicara berpikir bahwa basis data dari unit test bekerja harus memiliki data pra-populasi di dalamnya dan saya pikir itu harus benar-benar kosong sebelum dan setelah tes dijalankan.

Kekhawatiran saya dengan data pra-populasi dalam database adalah bahwa tidak ada cara untuk memastikan bahwa data dipertahankan dalam keadaan baik. Tes itu sendiri akan membuat, menghapus, dan memodifikasi data dalam database jadi saya benar-benar tidak melihat bagaimana memiliki data dalam database sebelum Anda memulai tes adalah hal yang baik.

Tampaknya cara terbaik untuk menguji fungsionalitas basis data adalah dengan memiliki pengaturan berikut:

1. Dalam fase "pengaturan" sebelum tes benar-benar berjalan, Anda terlebih dahulu memotong semua tabel dalam database
2. Kemudian Anda memasukkan semua data yang diperlukan untuk kasus uji yang akan Anda jalankan
3. Kemudian Anda menjalankan dan memvalidasi kasus uji
4. Kemudian dalam fase "teardown" Anda sekali lagi memotong semua tabel dalam database

Saya tidak melihat cara lain yang lebih baik untuk memastikan bahwa data yang Anda uji adalah tes yang bagus dan dapat diuji.

Apakah saya melewatkan sesuatu di sini? Apakah ini bukan cara terbaik untuk menguji fungsionalitas terkait database? Apakah ada manfaat memiliki basis data pra-populasi yang selalu ada dalam basis data (bahkan sebelum Anda memulai tes atau setelah tes selesai)? Setiap bantuan dalam ide untuk menjelaskan proses saya secara berbeda untuk lebih baik menyampaikan maksud saya juga akan menjadi besar (yaitu jika poin saya memiliki kelebihan).

Bagi saya tes unit tidak boleh berurusan dengan database, tes integrasi berhubungan dengan database.

Tes integrasi yang berhubungan dengan basis data harus dalam prakteknya memiliki basis data kosong dengan pendekatan sobek dan sobek, menggunakan pendekatan berbasis transaksi adalah cara yang baik untuk dilakukan (yaitu membuat transaksi pada pengaturan dan kembalikan pada sobek).

Apa yang ingin dilakukan oleh teman Anda adalah menguji dari sudut pandang 'regresi', yaitu memiliki data nyata di sana dan melihat bagaimana sistem bereaksi, setelah semua tidak ada sistem yang sempurna dan biasanya ada data buruk yang terletak di suatu tempat yang menyediakan beberapa kebiasaan untuk model domain Anda.

Praktik terbaik Anda adalah cara untuk pergi, dan apa yang cenderung saya lakukan, adalah jika saya menemukan skenario untuk data yang buruk, menulis tes integrasi dengan pengaturan naik dan turun dengan skenario yang tepat.

Jika tes Anda bergantung pada database, maka saya pikir lebih penting bahwa data yang Anda pedulikan berada dalam kondisi yang diketahui untuk pengujian Anda, daripada database menjadi kosong. Salah satu ukuran tes yang baik adalah bahwa setiap tes harus gagal karena satu alasan dan tidak ada tes lain yang gagal karena alasan yang sama.

Jadi, jika pengujian Anda peduli dengan keadaan data maka masukkan data ke dalam kondisi yang diketahui dan kembalikan data ke keadaan itu setelah tes Anda berjalan, sehingga tes Anda dapat direproduksi.

Jika Anda dapat memisahkan tes Anda dari keadaan data dengan mengejek maka itu juga akan menjadi hal yang baik. Anda menyebutkan Anda sedang melakukan pengujian unit / integrasi, tetapi tentu saja kedua hal tersebut harus dipertimbangkan secara terpisah. Tes unit Anda harus dipisahkan dari basis data jika memungkinkan dan uji integrasi Anda harus menguji dengan basis data dalam kondisi yang diketahui.

Yah, saya melihat satu manfaat dalam memiliki database yang telah diisi sebelumnya: Anda tidak harus menulis kode yang akan memasukkan data yang Anda butuhkan, karena ada di sana. Kalau tidak, hanya ada kekurangan. Mungkin seseorang memodifikasi data uji pada database? Mungkin seseorang mencoba menyegarkan data? Tetapi yang lebih buruk adalah memiliki satu test case yang mengacaukan basis data ... Anda akhirnya membuat ulang seluruh basis data secara manual beberapa kali.

Anda benar dalam bagaimana tes harus ditulis, kecuali bahwa saya tidak akan memotong apa pun:

• tahap setup: dapatkan koneksi ke database dan masukkan data
• menjalankan fase
• fase merobohkan: menghapus data yang dimasukkan (terpotong)

Sekarang, skenario itu bagus untuk pengujian unit. Ketika seseorang membutuhkan data untuk pengujian unit dan integrasi, saya menemukan bahwa satu fase pengaturan besar yang umum untuk semua kasus pengujian (kami mengelompokkan kembali semua "sisipan" menjadi satu metode statis) juga dapat bekerja dengan sangat baik. Ini seperti jalan tengah antara ide Anda dan ide teman Anda. Satu-satunya kelemahan adalah bahwa Anda harus sangat berhati-hati ketika menambahkan beberapa data baru agar tidak memecahkan kasus uji yang ada (tetapi jika Anda menambahkan seperti dua-tiga baris per tabel seperti yang kami lakukan, seharusnya tidak menjadi masalah)

Saya pikir Anda perlu mempersempit contoh dengan kolega Anda dan mencari tahu apa artinya sebenarnya. Anda mungkin berada di halaman yang sama.

Contoh: Memeriksa Tabel Transaksi Akun

1. Tidakkah Anda ingin menguji melihat tabel ini untuk pengguna / akun tanpa transaksi?
2. Tes menambahkan catatan pertama dan lihat apakah Anda dapat membuat keseimbangan.
3. Buat catatan saat sudah ada catatan dan periksa saldo berjalan dan aturan bisnis lainnya.
4. Lihat tabel dengan catatan yang ada dan semua CRUD lainnya.

Apakah Anda mencapai ini dengan menjalankan langkah 1 & 2 atau mulai dengan database yang sudah dalam kondisi ini (pulihkan cadangan?) Saya tidak yakin itu penting. Gagasan Anda untuk menuliskannya kepada saya membuatnya lebih mudah untuk mengelola setiap perubahan yang Anda butuhkan (Seperti jika Anda lupa membuat akun admin dan membutuhkannya untuk pengguna baru.). File skrip lebih mudah dimasukkan ke kontrol sumber daripada beberapa file cadangan. Ini juga akan terpengaruh oleh apakah Anda mendistribusikan aplikasi ini atau tidak.

Untuk menggambar beberapa aspek jawaban bersama dan menambahkan 2p ...

Catatan: komentar saya terutama berkaitan dengan pengujian basis data , dan bukan pengujian UI (meskipun jelas sama berlaku).

Database sama-sama membutuhkan pengujian seperti aplikasi front end tetapi cenderung diuji berdasarkan 'apakah ini bekerja dengan front end?' atau 'apakah laporan menghasilkan hasil yang benar?', yang menurut saya menguji sangat terlambat dalam proses pengembangan database dan tidak terlalu kuat.

Kami memiliki sejumlah klien yang menggunakan pengujian unit / integrasi / sistem untuk database data warehouse mereka selain UAT / kinerja / et al biasa. tes. Mereka menemukan bahwa dengan integrasi berkesinambungan dan pengujian otomatis, mereka mengambil banyak masalah sebelum sampai ke UAT tradisional, sehingga menghemat waktu dalam UAT dan meningkatkan peluang keberhasilan UAT.

Saya yakin sebagian besar akan setuju bahwa kekakuan yang serupa harus diterapkan pada pengujian basis data seperti pada pengujian ujung depan atau laporan.

Hal utama dengan pengujian adalah menguji entitas kecil yang sederhana, memastikan kebenarannya, sebelum melanjutkan ke kombinasi entitas yang kompleks, memastikan kebenarannya sebelum memperluas ke sistem yang lebih luas.

Jadi memberikan beberapa konteks untuk jawaban saya ...

Pengujian Unit

• memiliki fokus pengujian untuk membuktikan bahwa unit berfungsi, misalnya tabel, tampilan, fungsi, prosedur tersimpan
• harus 'mematikan' antarmuka untuk menghapus dependensi eksternal
• akan memberikan datanya sendiri. Anda memerlukan kondisi awal data yang diketahui, jadi jika ada kemungkinan data pra-tes yang ada, maka pemotongan / penghapusan harus terjadi sebelum populasi
• akan berjalan secara ideal dalam konteks eksekusi sendiri
• akan menjernihkan sendiri dan menghapus data yang digunakan; ini hanya penting ketika bertopik tidak digunakan.

Keuntungan melakukan ini adalah bahwa Anda menghapus semua dependensi eksternal pada tes dan melakukan jumlah pengujian terkecil untuk membuktikan kebenaran. Jelas, tes ini tidak dapat dijalankan pada basis data produksi. Mungkin ada sejumlah jenis tes yang akan Anda lakukan, tergantung pada jenis unitnya, termasuk:

• pemeriksaan skema, beberapa orang mungkin menyebutnya tes 'kontrak data'
• nilai kolom melewati
• pelaksanaan jalur logika dengan nilai data yang berbeda untuk fungsi, prosedur, tampilan, kolom terhitung
• pengujian kasus tepi - NULL, data buruk, angka negatif, nilai yang terlalu besar

(Unit) Pengujian Integrasi

Saya menemukan posting SE ini membantu dalam berbicara tentang berbagai jenis pengujian.

• memiliki fokus pengujian untuk membuktikan bahwa unit terintegrasi bersama
• dilakukan pada sejumlah unit bersama
• harus 'mematikan' antarmuka untuk menghapus dependensi eksternal
• akan memberikan data sendiri, untuk menghilangkan efek dari pengaruh data luar
• akan berjalan secara ideal dalam konteks eksekusi sendiri
• akan menjernihkan sendiri dan menghapus data yang dibuat; ini hanya penting ketika bertopik tidak digunakan.

Dalam beralih dari tes unit ke tes integrasi ini, sering kali akan ada sedikit lebih banyak data, untuk menguji berbagai kasus uji yang lebih luas. Jelas, tes ini tidak dapat dijalankan pada basis data produksi.

Ini kemudian dilanjutkan ke Pengujian Sistem , Pengujian Integrasi Sistem (alias pengujian ujung-2-ujung), dengan peningkatan volume data dan peningkatan cakupan. Semua tes ini harus menjadi bagian dari kerangka pengujian regresi. Beberapa tes ini mungkin dipilih oleh pengguna untuk dilakukan sebagai bagian dari UAT, tetapi UAT adalah tes yang ditentukan oleh pengguna , bukan seperti yang didefinisikan oleh IT - masalah umum!

Jadi sekarang saya telah memberikan beberapa konteks, untuk menjawab pertanyaan Anda yang sebenarnya

• data pra-populasi untuk pengujian unit dan integrasi dapat menyebabkan kesalahan pengujian palsu dan harus dihindari.
• Satu-satunya cara untuk memastikan pengujian yang konsisten adalah dengan tidak membuat asumsi tentang sumber data dan mengendalikannya dengan ketat.
• konteks pelaksanaan pengujian terpisah adalah penting, untuk memastikan bahwa satu tester tidak bertentangan dengan tester lain yang melakukan tes yang sama pada cabang kode sumber yang dikendalikan oleh basis data yang berbeda.

Terus terang saya pikir jika Anda melakukan pengujian unit tanpa database kira-kira ukurannya sama dengan database produksi yang ada, Anda akan memiliki banyak hal yang lulus tes dan gagal dalam produksi untuk kinerja. Tentu saja saya menentang orang yang mengembangkan basis data kecil untuk alasan ini juga.

Dan jika kode adalah data spesifik, bagaimana Anda bisa mengujinya secara efektif tanpa data? Anda tidak akan melihat jika kueri mengembalikan hasil yang benar. Mengapa Anda ingin mempertimbangkan pengujian terhadap database yang kosong, semua yang memberi tahu Anda adalah jika sintaksnya benar bukan jika kueri itu benar. Bagi saya itu nampaknya picik. Saya telah melihat terlalu banyak hal yang berjalan dan lulus tes yang pasti salah. Apakah Anda tidak ingin menemukannya dalam pengujian unit? Saya lakukan.