Hal yang harus diuji, dibandingkan dengan pengujian adalah, merupakan pertanyaan penting bagi semua tim. Pengujian adalah cara untuk mencapai tujuan, dan memilih cara memprioritaskan pengujian berbagai bagian codebase Anda bisa jadi sulit.
Cara terbaik untuk membuat prioritas adalah berdasarkan codebase dan sasaran tim Anda. Namun, penting untuk diingat, meskipun dibutuhkan sedikit waktu dan bandwidth untuk menulis banyak pengujian kecil (di bagian bawah piramida pengujian, seperti pengujian unit) yang memiliki banyak cakupan kode, hal tersebut tidak selalu mengurangi risiko keseluruhan untuk project Anda.
Anda dapat memilih apa yang akan diuji terlebih dahulu dengan mempertimbangkan kasus penggunaan utama aplikasi, situs, atau library Anda. Hal ini dapat dilakukan dengan menulis pengujian komponen pada bagian penting situs Anda, komponen inti yang mendukung pengalaman pengguna. Misalnya, developer situs yang mengizinkan pengguna mengupload dan mengelola data deret waktu harus membayangkan dan menguji berbagai cara yang dapat dilakukan pengguna untuk melakukan tugas-tugas tersebut.
Pendekatan lain dalam menentukan prioritas melibatkan pengumpulan informasi paling banyak. Jika Anda memiliki bagian codebase lama yang "berbahaya", lama, atau ditulis dengan buruk yang tidak disukai oleh siapa pun di tim Anda, sebaiknya buat pengujian di sekitarnya agar perilakunya lebih konsisten sebelum Anda mengabaikannya lebih lanjut, atau memfaktorkan ulang untuk memperbaikinya. Anggap saja ini seperti peran scaffolding untuk gedung yang telah dikecam, tetapi masih menampung pusat data Anda.
Dimensi
Kami telah memperkenalkan konsep piramida pengujian, atau bentuk pengujian lainnya, tetapi bentuk ini cenderung hanya menyajikan satu dimensi pengujian: garis yang dimulai dari cakupan kecil, pengujian unit sederhana hingga pengujian yang kompleks dan luas—pengujian unit versus pengujian integrasi versus pengujian menyeluruh.
Namun, beberapa daftar panjang jenis pengujian yang mungkin tidak merepresentasikan tingkat kompleksitas, tetapi merepresentasikan sasaran atau teknik pengujian. Misalnya, uji asap adalah kategori pengujian yang berbeda yang dapat berupa pengujian unit, menyeluruh, atau pengujian lainnya, tetapi dimaksudkan untuk memberikan keyakinan keseluruhan kepada penguji bahwa project yang sedang diuji dalam status valid. Pengujian visual juga dapat berguna jika diterapkan pada komponen kecil, atau di situs Anda secara keseluruhan.
Codebase Anda akan memiliki persyaratan unik. Misalnya, bisa jadi jauh lebih penting dalam codebase Anda untuk menyelaraskan pada satu fitur, dengan menulis berbagai jenis pengujian untuk memastikan bahwa fitur tersebut berfungsi dengan benar. Fitur baru yang memerlukan pengujian jarang berupa komponen, fungsi, atau pendekatan tunggal, dan dampaknya pada project Anda mungkin didistribusikan secara luas dan pada skala yang berbeda.
Prioritas pengujian mungkin juga bergantung pada kebutuhan bisnis Anda. Sistem yang sangat teknis mungkin memerlukan pengujian unit yang kompleks untuk mengonfirmasi bahwa algoritma unik berperforma benar, sedangkan alat yang sangat interaktif cenderung berfokus pada pengujian visual atau pengujian menyeluruh untuk mengonfirmasi bahwa input sentuh yang kompleks menghasilkan respons yang benar.
Pendekatan Anda terhadap pengujian
Cobalah untuk fokus pada pengujian kasus penggunaan codebase Anda, terlepas dari skalanya. Bayangkan bagaimana pengguna dapat menggunakan bagian mana pun dari project Anda—hal ini mungkin mewakili satu komponen, atau fungsi tingkat rendah, atau kasus penggunaan end-to-end tingkat tinggi. (Hal ini juga dapat mengungkapkan kekurangan dalam abstraksi Anda pada skala apa pun, jika Anda mendapati bahwa pengujian Anda tidak dapat berinteraksi secara rapi dengan kode yang sedang diuji.)
Setiap kasus pengujian harus memiliki tujuan yang jelas. Pengujian "catch-all" yang besar dapat sulit dilakukan, seperti pada kode non-pengujian.
Sisi lain dari pengembangan yang didorong oleh pengujian
Pengembangan berbasis pengujian (TDD) adalah pendekatan unik untuk pengujian—ortogonal terhadap skala atau jenis—yang melibatkan penulisan pengujian yang dimaksudkan untuk gagal, setidaknya pada awalnya. Hal ini dapat berlaku untuk pengujian manual dan otomatis: Anda menjelaskan sasaran yang ingin Anda capai, mencari tahu apa yang kurang dalam solusi atau kode Anda saat ini, dan menggunakan pengujian yang gagal sebagai panduan untuk menemukan solusi.
Tentu saja, tidak ada gunanya menguji setiap kemungkinan skenario dalam aplikasi atau komponen fiktif bahkan sebelum Anda mulai membuatnya. TDD memiliki perannya sendiri, dan dapat berguna saat codebase Anda menjadi lebih kompleks.
TDD juga merupakan praktik yang baik saat memperbaiki {i>bug<i}. Jika Anda dapat mengodifikasi kasus reproduksi bug untuk bug, pengujian ini dapat dimasukkan ke dalam pengujian otomatis yang pada awalnya akan gagal. Setelah Anda memperbaiki bug, pengujian akan lulus, sehingga Anda dapat menentukan apakah perbaikan berhasil tanpa konfirmasi manual.
Kotak buram versus kotak bening
Ini mengacu pada cara Anda menguji bagian mana pun dari sistem Anda. Jika buram, Anda tidak akan dapat melihat bagian dalam, misalnya, saat menggunakan antarmuka publik class, bukan memeriksa internalnya.
Kecuali jika Anda memiliki alasan khusus untuk tidak melakukannya, sebaiknya mulai dengan pengujian kotak buram sehingga Anda dapat mendesain pengujian berdasarkan cara komponen digunakan, dan tidak terganggu oleh cara kerja internalnya. Jika Anda hanya mengandalkan antarmuka "publik" jalur kode (tidak harus publik untuk pengguna, tetapi mungkin untuk bagian lain dari kode), Anda bebas memfaktorkan ulang dan meningkatkan kode tersebut dengan mengetahui bahwa pengujian Anda akan mendeteksi setiap perubahan.
Salah satu cara untuk mengubah kode "clear box" Anda menjadi lebih buram adalah dengan memperkenalkan elemen yang dapat dikonfigurasi seperti abstraksi untuk dependensi kode, atau callback untuk mengamati status, bukan status yang dikaitkan secara erat dengan sistem lain. Hal ini membuat kode Anda lebih terpisah dan memungkinkan Anda menyediakan versi 'pengujian'. Atau, Anda dapat membuat tiruan tempat kode Anda berinteraksi dengan sistem lain.