TDD dengan SQL dan fungsi manipulasi data

Walaupun saya seorang programmer profesional, saya tidak pernah dilatih secara formal dalam rekayasa perangkat lunak. Karena saya sering berkunjung ke sini dan SO, saya memperhatikan kecenderungan untuk menulis pengujian unit bila memungkinkan dan, karena perangkat lunak saya menjadi lebih kompleks dan canggih, saya melihat pengujian otomatis sebagai ide yang baik dalam membantu debugging.

Namun, sebagian besar pekerjaan saya melibatkan penulisan SQL yang kompleks dan kemudian memproses output dalam beberapa cara. Bagaimana Anda menulis tes untuk memastikan SQL Anda mengembalikan data yang benar, misalnya? Kemudian, katakanlah jika data tidak berada di bawah kendali Anda (mis., Dari sistem pihak ke-3), bagaimana Anda dapat dengan efisien menguji rutinitas pemrosesan Anda tanpa harus menulis rim data dummy?

Solusi terbaik yang dapat saya pikirkan adalah membuat tampilan data yang, bersama-sama, mencakup sebagian besar kasus. Saya kemudian dapat bergabung dengan pandangan-pandangan itu dengan SQL saya untuk melihat apakah itu mengembalikan catatan yang benar dan secara manual memproses pandangan untuk melihat apakah fungsi saya, dll. Melakukan apa yang seharusnya. Meski begitu, tampaknya berlebihan dan serpihan; khususnya menemukan data untuk diuji terhadap ...

Aturan penting untuk menguji segala sesuatu yang terkait dengan basis data adalah mengisolasinya sepenuhnya dari aplikasi Anda yang lain.

The port dan adapter arsitektur adalah contoh yang benar-benar baik. Basis data dianggap sebagai plugin eksternal melalui adaptor ke aplikasi Anda. Hal yang sama berlaku untuk semua subsistem pihak ke-3. Untuk menguji bagaimana aplikasi Anda akan berperilaku dan menginterpretasikan tanggapan dari subsistem pihak ke-3 satu-satunya cara saya tahu bagaimana menguji yaitu dengan mematikan tanggapan dari subsistem individu ini. Saya tidak harus berarti bahwa Anda harus secara manual menulis semua objek data. Anda dapat dengan mudah mengambil pendekatan menggunakan pengujian berbasis data.

Berkenaan dengan pengujian bagaimana aplikasi Anda berinteraksi dengan basis data Anda, Anda dapat memalsukan adaptor basis data untuk menggunakan basis data dalam memori misalnya.

Sekarang sedang menguji permintaan basis data Anda. Pertama-tama, semua kueri kompleks harus diuraikan dalam kueri yang lebih mudah, sederhana, dan dapat diprediksi. Hal yang sama akan Anda lakukan untuk kelas lemak atau fungsi lemak. Ada alat yang dapat membantu Anda menguji basis data Anda seperti Dbunit. Pendekatan sederhana yang terkadang saya ambil adalah menggunakan konsep tes karakterisasi. Jadi saya akan meletakkan database dalam keadaan tahu, jalankan semua pertanyaan yang saya harus tulis simpan output di suatu tempat (file, memori) dan anggap output ini sebagai yang benar. Berjalan berikutnya akan membandingkan output mereka dengan yang satu ini, sehingga pasti akan menawarkan saya pengujian regresi yang saya butuhkan. Memang output pertama tidak dijamin benar tetapi masalah regresi dapat diselesaikan dengan cara ini. Jika kueri Anda terurai dengan baik, Anda dapat mengujinya secara individual ke dalam basis data yang dikenal.

Itu adalah pertanyaan yang menarik karena database biasanya merupakan bagian yang dipalsukan selama pengujian unit aplikasi. Semoga logika dari mesin basis data itu sendiri diuji dengan baik oleh penyedia tetapi tentu saja pertanyaan, skema, dan prosedur tersimpan adalah kode yang perlu diuji dan dilindungi terhadap regresi. Ini sering diserahkan pada pengujian integrasi yang bukan TDD.

Tampilan kemungkinan akan menjadi cara yang sulit untuk melakukannya karena mereka tidak benar-benar meminjamkan untuk pengujian lampu merah pertama, pengujian otomatis lampu hijau dari satu aspek per tes yang lebih disukai dalam TDD. Juga dengan tampilan Anda tidak dapat menulis tes terlebih dahulu sebelum kode. Pendekatan yang lebih baik adalah menulis prosedur tersimpan di mana Anda dapat menambahkan logika "tegaskan" dalam prosedur (misalnya menggunakan pernyataan "jika") untuk menguji output untuk kegagalan. Anda perlu menguji hanya satu hal di setiap unit tes untuk mengisolasi unit, dan metode SP akan lebih cocok untuk itu. Juga, dengan SP, Anda dapat menjalankan seluruh rangkaian sebagai skrip saat Anda mengembangkan kode awal dan nanti saat menguji untuk regresi saat melakukan refactoring.

Perlu diketahui juga bahwa pengujian harus dapat diulang dan Anda akan memerlukan beberapa skrip untuk menginisialisasi dan merobohkan status basis data untuk memastikan bahwa keadaannya sama untuk setiap pengujian unit.

Untuk pertanyaan Anda tentang data yang tidak di bawah kendali Anda, itu adalah bidang yang sulit. Saya pikir Anda lebih baik mengejeknya dengan data palsu dan menguji kondisi pengecualian dan tepi sebanyak mungkin untuk unit test. Kalau tidak, itu akan jatuh lebih ke dalam kategori pengujian integrasi (yang juga merupakan hal yang baik untuk dilakukan). Untuk pengujian integrasi, Anda dapat menjalankan pengujian terhadap data pihak ke-3 dan membiarkannya menghasilkan output awal dan untuk pengujian selanjutnya (mis. Setelah refactoring) memastikan output tersebut mengulangi output awal yang diketahui.

Pada titik tertentu Anda akan membutuhkan data pengujian. Jika Anda menggunakan sistem pihak ke-3, skema sudah dibuat, tetapi Anda harus mengatasi perubahan di masa depan. Mudah-mudahan, Anda bisa mendapatkan perubahan ini dari dokumentasi pemutakhiran, tetapi Anda mungkin terpaksa membandingkan versi database sendiri.

Set hasil yang diharapkan dapat disimpan dalam tabel basis data atau file / spreadsheet eksternal. Saya bahkan pernah melihat CHECKSUM digunakan atau perbandingan. Saat Anda menguji tampilan / sproc, Anda akan mendapatkan kegagalan karena tidak ada. Kemudian Anda membuat objek dengan kode yang cukup untuk setidaknya mengeksekusi (SELECT -1 sebagai [salah_data];) dan Anda akan mendapatkan kegagalan karena tidak cocok dengan hasil yang ditetapkan. Begitu mereka cocok, Anda memiliki lampu hijau Anda.

Saya sudah mulai bekerja dengan pemilik proyek dan meminta mereka untuk mengejek laporan dalam spreadsheet dan mencoba memunculkan data parsial untuk saya (Anda bisa memasukkan data hasil dalam tabel uji.). Pada awalnya ada beberapa pushback, tetapi mereka menyadari bahwa saya akan membuat laporan dan mereka harus memverifikasinya. Ini telah menghemat waktu dalam jangka panjang. Jika mereka ingin membuat permintaan perubahan, mereka harus mengulang kembali spreadsheet. Sekarang mereka dapat menjawab pertanyaan, "Seberapa sulit untuk menambahkan ...?"

Jika platform basis data Anda adalah SQL Server, ada alat gratis yang sangat bagus: tSQLt .

tSQLt adalah kerangka kerja pengujian unit database untuk Microsoft SQL Server. tSQLt kompatibel dengan SQL Server 2005 (paket layanan 2 diperlukan) dan di atas pada semua edisi.

Saya telah berhasil menerapkan pengujian di tingkat basis data.

Beberapa elemen kunci yang membuatnya sangat berguna termasuk:

• Kemampuan untuk bekerja dengan tabel dan tampilan palsu yang mengurangi pengaturan normal yang terlibat
• Tes secara otomatis dijalankan dalam transaksi (sehingga mudah dijalankan kembali)
• Pernyataan Anda dapat melakukan perbandingan pada tabel (baik nyata maupun palsu) sehingga Anda dapat melihat apakah Anda telah mengubah data dengan mudah