Saya ingin memulai dengan mengatakan semua yang saya lakukan adalah SQL Server jadi itu adalah contoh yang saya berikan. Namun secara umum ini berlaku untuk segala bentuk kode terlepas dari sistem.
Mari kita mulai dengan memecah ini sedikit.
Upgrade
Anda memiliki sistem dan akan meningkatkan sebagian atau semuanya. Misalnya meningkatkan instance dari SQL Server 2012 ke 2014. Pada titik ini pengujian sangat penting. Sayangnya menguji setiap bagian bahkan dari aplikasi kecil mungkin tidak akan mungkin. Pada titik itu saya akan melakukan apa yang saya sebut tes "bekerja". Apakah sistem dasar berfungsi. Jalankan melalui tugas-tugas umum Anda mulai dari selesai. Jangan menguji setiap opsi, hanya jalur utama.
Ketika melakukan upgrade SQL Server ada juga beberapa bacaan wajib . Pada dasarnya Anda ingin membaca Backward Compatibilityentri untuk versi baru (di sini adalah 2014 ) dan pastikan bahwa Anda tidak memiliki apa pun di salah satu daftar (melanggar perubahan, perubahan perilaku dll).
Kode Aplikasi
Di sini kita melihat baru / mengubah kode aplikasi (karena tentu saja apa pun yang sudah ada sudah diuji kan?). Dalam hal ini semuanya harus diuji. Anda harus mengatur kasus uji terlebih dahulu dan menjalankan setidaknya sebagian besar fitur yang terpengaruh. Lebih disukai pada titik ini Anda juga harus meminta orang lain melakukan pemeriksaan serupa. Kode ini akan ada di tempat, mungkin untuk waktu yang cukup lama, dan digunakan oleh sejumlah besar orang. Anda ingin memastikan itu berfungsi dan berfungsi dengan baik.
Salah satu hal yang dapat sangat membantu dengan ini adalah untuk menghasilkan satu set unit testsyang mudah diulang. Steve Jones merekomendasikan untuk menggunakan tSQLt untuk menguji kode TSQL Anda (hanya SQL Server yang saya khawatir). Tetapi dengan melakukan ini, Anda dapat menjalankan serangkaian tes tetap dengan cepat dan itu akan sangat membantu dalam pengujian regresi (menguji semuanya, katakan sebelum melakukan upgrade).
Fitur / Konfigurasi
Bahkan lebih dari perubahan kode aplikasi Anda ingin menguji fitur baru dan perubahan konfigurasi secara menyeluruh. Jika misalnya Anda memutuskan untuk mulai bekerja dengan indeks toko kolomuntuk pertama kalinya Anda perlu menguji setiap bagian kode yang menyentuh tabel yang terpengaruh. Gunakan unit test yang Anda hasilkan untuk menguji aplikasi Anda. Fitur-fitur ini mungkin baru bagi Anda (dan mungkin baru di platform) dan mungkin akan memiliki beberapa gotcha yang tidak Anda harapkan. Adapun perubahan konfigurasi, Anda berbicara tentang sesuatu yang dapat mempengaruhi seluruh sistem Anda, mungkin secara signifikan. Aturan praktisnya adalah untuk menguji, dan menguji dengan hati-hati. Ada beberapa perubahan yang Anda tidak akan benar-benar melihat sampai Anda masuk ke sistem yang aktif (mungkin hanya sistem produksi Anda) tetapi itu bukan alasan untuk tidak mencobanya di lingkungan pengujian terlebih dahulu.
Permintaan khusus yang merujuk / memengaruhi data pengguna
Ketika Anda memiliki kode yang memengaruhi data pengguna Anda, umumnya Anda perlu mengujinya, bahkan, dan mungkin terutama, karena itu Ad Hoc. Sekarang dikatakan jika Anda menjalankan kode yang sama, berulang-ulang, hanya dengan parameter yang berbeda, maka Anda mungkin tidak perlu khawatir tentang pengujian setiap kali.
Misalnya, Anda perlu menghapus satu atau lebih iklan dari tabel AdList setiap kuartal.
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
Pada saat itu Anda sudah menguji kode (Anda hanya mengubah string tetap) dan mungkin cukup aman hanya menjalankan kode (dengan asumsi Anda memiliki cadangan yang baik untuk berjaga-jaga).
Salah satu cara mudah untuk menguji DELETE, UPDATEatau INSERTmengubahnya menjadi SELECT dan menjalankannya, lalu konfirmasikan bahwa jumlah dan jenis baris yang Anda harapkan dikembalikan.
Anda mungkin berpikir bahwa Anda tidak perlu menguji SELECTkarena mereka tidak benar-benar mengubah data apa pun. Namun Anda menjalankan kode karena suatu alasan, bukan? Katakanlah Anda sedang melakukan penelitian untuk manajer Anda, yang pada gilirannya akan menyerahkan data ini kepada manajer mereka dan seterusnya. Anda menguji untuk memastikan bahwa Anda tidak mendapatkan data yang salah (atau memblokir orang lain dari mengumpulkan data mereka).
Permintaan khusus yang merujuk / memengaruhi data sistem
Ini mungkin satu-satunya pengecualian untuk aturan "uji segalanya". Anda menjalankan kueri informasi pada data sistem. Yang penting di sini adalah mendapatkan kembali data yang Anda harapkan. Jika kueri itu sesuatu yang sederhana (meng-query tampilan sistem) maka Anda mungkin baik-baik saja selama Anda telah memeriksa apa arti sebenarnya dari tampilan / kolom. Jika kueri itu rumit (katakanlah mencapai 3 atau 4 tampilan sistem dengan perhitungan pada kolom yang dikembalikan) maka Anda mungkin ingin menjalankan beberapa tes hanya untuk memastikan Anda akan mendapatkan kembali data yang Anda harapkan.
Ringkasan
Singkatnya, ya, Anda ingin menguji semuanya. Jika cukup penting bagi Anda untuk menulis dan menjalankannya, maka itu cukup penting untuk Anda uji. Itu tidak berarti Anda harus menghabiskan banyak waktu untuk menguji setiap cabang dari setiap baris kode. Tetapi beberapa tingkat pengujian perlu dilakukan.
Pengujian unit otomatis adalah teman Anda di sini. Dengan munculnya DevOpsdan Continuous IntegrationAnda akan melihat semakin banyak aplikasi dan metode pengujian kode Anda dengan cepat dan mudah. Tentu saja itu memang membutuhkan memiliki lingkungan pengujian dan data yang baik untuk ikut serta, tapi itu diskusi yang berbeda.
