Database dan Pengujian Unit / Integrasi


25

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).


Jawaban:


21

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.


Saya hanya saya perhatikan yakin apa perbedaan antara pengujian unit dan pengujian integrasi selain saya mendengar unit harus menggunakan data tiruan dan integrasi harus menggunakan database (mulai thread lain programmer .stackexchange.com/questions/ 101300/... untuk mengetahui perbedaannya ). Selain itu, semua yang Anda katakan tampaknya sejalan dengan apa yang saya pikirkan.
ryanzec

Tidak masalah, saya telah menambahkan lebih banyak informasi ke jawaban Anda yang lain
Nicholas Mayne

1
mengapa Anda tidak bisa menguji DB? Jika Anda memasukkan SQL ke dalam prosedur tersimpan, Anda dapat mengujinya dengan data yang ditentukan tes, dan tiba-tiba semuanya mudah. Ini jelas merupakan praktik terbaik yang harus diikuti lebih banyak orang, lihat apa yang dikatakan MS
gbjbaanb

1
integration tests- apa maksudmu? Seperti yang saya sebutkan modul yang menggunakan database dapat dan harus diuji dengan unit test. Basis data dapat saya tiru secara manual atau diganti dengan implementasi dalam memori
hellboy

6

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.


2

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)


Bukankah saya lebih suka membuat bagian-bagian dari database yang dibutuhkan masing-masing untuk pengujian daripada seseorang secara tidak sengaja memodifikasi data dengan cara yang menyebabkan kegagalan? Harus memastikan data benar ketika tes gagal sepertinya sesuatu yang dapat dicegah.
ryanzec

1
Fase pengaturan besar yang memasukkan data yang berguna untuk berbagai kasus pengujian mungkin hanya berguna untuk pengujian integrasi di mana Anda perlu memeriksa berbagai bagian aplikasi yang bekerja bersama. Mungkin patut memiliki set "sisipan" besar yang umum ini karena Anda kemungkinan besar akan membutuhkan beberapa dari mereka untuk tes integrasi lainnya. Kalau tidak, jika kita hanya berbicara pengujian unit murni, saya benar-benar memiliki satu set data untuk dimasukkan untuk setiap kasus uji.
Jalayn

1

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.


0

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.

-3

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.


Saya tidak menganjurkan menjalankan terhadap database kosong, jika Anda melihat langkah 2 saya punya "Lalu Anda memasukkan semua data yang diperlukan untuk kasus uji yang akan Anda jalankan". Tentang masalah kinerja, saya tidak berpikir untuk apa pengujian unit, itu lebih banyak pengujian beban. Unit pengujian kepada saya untuk menguji memastikan logis dalam pekerjaan kode Anda. jika logis bekerja, itu akan berfungsi untuk 1 catatan atau 100.000.000.000 catatan dari data dasar yang sama (berpikir itu akan jauh lebih lambat).
ryanzec

Kueri basis data bukan hanya tentang logika dan semakin cepat Anda mengetahuinya, itu tidak akan berfungsi dengan baik. Apa yang berfungsi untuk 1 record sering kali akan habis pada prod dan uji unit harus menunjukkan itu sesegera mungkin.
HLGEM

Tes unit dan integrasi adalah untuk fungsionalitas dan bukan kinerja sehingga Anda dapat menguji dengan sejumlah kecil data
user151019

Pengujian unit tidak boleh menggunakan database - tes integrasi menggunakan database.
Nicholas Mayne

1
Apa yang sebenarnya Anda bicarakan adalah pengujian beban. Jika Anda memiliki satu set tes Penerimaan dan mengaitkannya ke alat pengujian beban, Anda akan dapat mencapai efek yang diinginkan.
Nicholas Mayne
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.