Ada beberapa alat uji yang berbeda untuk PL/SQL di luar sana. Steven Feuerstein telah menulis dua di antaranya, utplsql dan Penguji Kode Quest untuk Oracle (sebelumnya QUTE). Saya penggemar berat utplsql, tetapi tidak lagi memiliki komunitas pendukung aktif (yang memalukan). Ini juga cenderung cukup bertele-tele, terutama dalam hal menyiapkan perlengkapan uji. Itu memang memiliki virtual kardinal menjadi paket PL/SQL murni; kode sumbernya agak kasar tetapi FOSS.
QCTO hadir dengan GUI, yang berarti - seperti produk Quest lainnya yaitu TOAD - hanya untuk Windows. Itu tidak mengotomatiskan pembuatan data pengujian, tetapi menyediakan antarmuka untuk mendukungnya. Juga seperti produk Quest lainnya, QCTO dilisensikan meskipun ada salinan freeware.
Steven (pengungkapan, dia adalah salah satu pahlawan Oracle saya) telah menulis perbandingan fitur dari semua alat pengujian PL/SQL. Jelas, QOTC keluar sebagai yang teratas, tetapi saya pikir perbandingannya jujur. Lihatlah.
Saran tentang perlengkapan pengujian di utplsql
Mengelola data pengujian untuk pengujian unit bisa sangat merepotkan. Sayangnya utplsql tidak menawarkan banyak untuk menanggung beban. Jadi
- Selalu uji terhadap nilai yang diketahui :
- Hindari penggunaan dbms_random;
- Cobalah untuk membatasi penggunaan urutan ke kolom yang nilainya tidak penting;
- Tanggal juga rumit. Hindari tanggal hard-coding:gunakan variabel yang diisi dengan sysdate. Belajar menghargai
add_months(),last_day(),interval,trunc(sysdate, 'MM'), dll.
- Mengisolasi data pengujian dari pengguna lain. Bangun dari awal. Gunakan nilai yang berbeda jika memungkinkan.
- Hanya buat data pengujian sebanyak yang Anda butuhkan. Pengujian volumetrik adalah tanggung jawab yang berbeda.
- Saat menguji prosedur yang mengubah data, buat catatan khusus untuk setiap pengujian unit.
- Juga:jangan mengandalkan hasil yang berhasil dari satu pengujian untuk memberikan masukan dari pengujian lain.
- Saat menguji prosedur yang hanya melaporkan catatan berbagi data di antara pengujian unit bila perlu.
- Bagikan data kerangka kerja (misalnya, kunci utama yang direferensikan) bila memungkinkan.
- Gunakan bidang teks bebas (nama, deskripsi, komentar) untuk mengidentifikasi pengujian atau pengujian mana yang menggunakan catatan.
- Minimalkan pekerjaan yang terlibat dalam membuat catatan baru:
- Hanya tetapkan nilai yang diperlukan untuk rangkaian pengujian dan batasan tabel;
- Gunakan nilai default sebanyak mungkin;
- Buat prosedur sebanyak mungkin.
Hal lain yang perlu diingat:
- menyiapkan perlengkapan tes bisa menjadi latihan yang memakan waktu. Jika Anda memiliki banyak data, pertimbangkan untuk membuat prosedur untuk menyiapkan data statis yang dapat dijalankan satu kali per sesi, dan hanya menyertakan data volatil di
ut_setupdiri. Ini sangat membantu saat menguji fungsionalitas hanya-baca. - ingat bahwa membuat data uji adalah latihan pemrograman tersendiri, dan sangat rentan terhadap bug.
- gunakan semua fitur utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountdanutAssert.Eq_RefC_Querysemuanya adalah fitur yang sangat berguna dalam hal menyimpulkan nilai data yang mudah menguap. - saat mendiagnosis uji coba yang tidak berjalan seperti yang kami harapkan, data yang digunakan dapat berguna. Jadi pertimbangkan untuk memiliki
ut_teardownyang kosong prosedur dan menghapus data pengujian di awalut_setup.
Berurusan dengan kode lawas
Mengomentari posting Gary mengingatkan saya pada satu hal lain yang mungkin berguna bagi Anda. Steven F menulis ulplsql sebagai implementasi PL/SQL dari JUnit, pelopor Java dari gerakan Test First. Namun, teknik TDD juga dapat diterapkan ke sejumlah besar kode warisan (dalam konteks ini, kode warisan adalah kumpulan program apa pun tanpa pengujian unit apa pun).
Hal utama yang perlu diingat adalah Anda tidak harus segera mendapatkan semuanya di bawah unit test. Mulai secara bertahap. Buat pengujian unit untuk hal-hal baru, Uji Dulu . Buat pengujian unit untuk bit yang akan Anda ubah sebelum menerapkan perubahan, sehingga Anda tahu bahwa bit tersebut masih berfungsi setelah Anda melakukan perubahan.
Ada banyak pemikiran di bidang ini, tetapi (tidak dapat dihindari jika memalukan) itu terutama berasal dari programmer OO. Michael Feathers adalah tokoh utama. Baca artikelnya Bekerja Secara Efektif Dengan Kode Lama . Jika Anda merasa terbantu, dia kemudian menulis buku dengan nama yang sama.
