Fixture data identitas untuk pengujian yang dapat diulang

Fixture data identitas adalah sekumpulan catatan tetap yang dipakai berulang kali oleh pengujian, bukan dibuat baru setiap kali dijalankan. Karena nilainya sudah diketahui sebelum pengujian dimulai, hasilnya dapat dibandingkan dari satu versi ke versi berikutnya. Tulisan ini membahas cara menyimpan catatan seperti itu, apa yang membuatnya tetap sah seiring waktu, dan kapan menyimpan catatan justru lebih merepotkan daripada membangkitkannya ulang.

Apa yang dimaksud dengan fixture data identitas?

Istilah ini merujuk pada bahan pengujian yang disiapkan lebih dahulu dan disimpan bersama kode pengujiannya. Isinya bisa satu berkas berisi sepuluh catatan, bisa juga beberapa kelompok catatan yang masing-masing mewakili keadaan tertentu: pengguna baru tanpa riwayat, pengguna dengan dua alamat, pengguna yang belum melengkapi data.

Bahan semacam ini berbeda dari data yang dibangkitkan saat pengujian berjalan. Data yang dibangkitkan selalu segar dan tidak pernah basi, tetapi nilainya berubah setiap kali, sehingga perbandingan hasil antarjalur menjadi lebih sulit. Fixture mengorbankan kesegaran demi keteraturan, dan itu pertukaran yang wajar selama ada yang bertanggung jawab merawatnya.

Baris ketiga adalah jalur tengah yang paling sering berguna. Nilai keluarannya tidak berubah selama kuncinya tidak berubah, tetapi Anda tidak perlu menyimpan satu pun catatan di dalam repositori. Bila aturan format berubah, cukup pembangkitnya yang disesuaikan, dan seluruh catatan mengikuti tanpa perlu disunting satu per satu.

Mengapa nilainya harus tetap sama setiap kali dijalankan?

Karena pengujian yang hasilnya berubah-ubah sulit dipercaya. Bila pengujian gagal, hal pertama yang ingin Anda ketahui adalah apakah kegagalan itu disebabkan oleh perubahan kode atau kebetulan nilai masukan yang berbeda. Bila nilai masukannya selalu sama, pertanyaan itu hilang dengan sendirinya.

Nilai yang tetap juga memudahkan penelusuran. Ketika seorang penguji melaporkan bahwa catatan tertentu menghasilkan tampilan yang salah, catatan itu dapat dibuka kembali persis dengan isi yang sama. Tanpa itu, laporan hanya bisa menggambarkan gejala tanpa bahan yang dapat diperiksa ulang.

Ada satu jebakan yang perlu dihindari. Fixture yang terlalu sering dipakai bersama akhirnya menjadi tempat bergantung bagi banyak pengujian sekaligus, sehingga satu perubahan kecil pada isinya mematahkan banyak pengujian sekaligus. Sebaiknya pisahkan bahan berdasarkan tujuan: satu kelompok untuk pengujian alamat, satu untuk pengujian identitas, dan biarkan pengujian yang benar-benar berbeda memakai bahannya sendiri.

Apakah fixture boleh memuat data orang nyata?

Tidak. Ini kesalahan yang paling sering terjadi karena tampak paling praktis: mengambil beberapa baris dari basis data sungguhan agar formatnya pasti benar. Masalahnya, begitu catatan itu masuk ke repositori, ia ikut tersalin ke setiap komputer yang mengambil kode tersebut, dan tidak ada cara menariknya kembali dengan mudah.

Data seperti ini hanya untuk pengujian dan tidak boleh dipakai untuk menyamar sebagai orang lain. Catatan yang tampak wajar secara format tetap bukan identitas siapa pun, dan tidak dirancang untuk melewati verifikasi identitas atau membuka akun sungguhan. Karena itu, isi fixture sebaiknya berasal dari pembangkit, bukan dari salinan.

Ada pula sisi praktis yang sering diabaikan: catatan asli menjadi basi. Nomor telepon berganti, alamat berubah, dan orang menutup akunnya. Fixture yang memuat catatan asli akan mulai gagal karena sebab yang tidak ada hubungannya dengan kode yang sedang diuji.

Kapan fixture sebaiknya dibangkitkan, bukan disimpan?

Ada tiga keadaan yang biasanya menandakan sudah waktunya berhenti menyimpan. Pertama, ketika aturan format sering berubah, karena setiap perubahan menuntut penyuntingan manual pada seluruh catatan. Kedua, ketika jumlah catatan yang dibutuhkan terus bertambah, karena berkas yang membengkak sulit ditinjau ketika ada perubahan. Ketiga, ketika catatan yang disimpan tidak lagi menyerupai bentuk data yang sebenarnya, sehingga pengujian lolos pada keadaan yang tidak pernah terjadi.

Sebaliknya, menyimpan catatan tetap berguna ketika Anda perlu membandingkan hasil antarversi, ketika catatan itu mewakili kasus batas yang sulit dihasilkan secara acak, atau ketika sebuah kesalahan hanya muncul pada satu nilai tertentu dan Anda ingin memastikan nilai itu selalu ikut diuji.

Tanda paling jelas bahwa fixture perlu diganti adalah ketika tidak ada lagi yang tahu mengapa sebuah nilai ada di dalamnya. Catatan yang bertahan tanpa alasan biasanya sudah tidak diuji oleh apa pun, tetapi tetap ikut disalin dan dirawat.

Bagaimana fixture dibagi ke seluruh tim?

Karena berkas bahan pengujian ikut tersimpan bersama kode, setiap orang di tim menerima nilai yang sama. Sisi baiknya jelas: hasil yang dilaporkan satu orang dapat diperiksa ulang oleh orang lain tanpa perlu menyiapkan apa pun. Sisi buruknya, kesalahan yang menyangkut perbedaan lingkungan juga ikut tersebar dan tampak seperti masalah pada kode.

Ambil contoh yang paling sering muncul, yaitu nilai dengan tanda diakritik atau aksara non-Latin. Bila berkasnya tidak disimpan dan dibaca dengan pengkodean yang sama di semua tempat, sebuah nama yang tampak benar di satu komputer dapat berubah menjadi deretan tanda tanya di komputer lain. Kesalahan seperti ini tidak ada hubungannya dengan logika program, tetapi bisa menghabiskan waktu berjam-jam. Menyimpan bahan pengujian dalam bentuk yang dibangkitkan dari kunci menghilangkan sebagian besar masalah tersebut, karena yang berpindah antar komputer hanyalah kuncinya, bukan deretan aksara yang sensitif terhadap pengkodean.

Hal yang sama berlaku untuk waktu. Waktu mesin yang berbeda zona dapat membuat catatan yang sama dianggap berbeda umur, terutama bila ada bidang yang dihitung dari tanggal sekarang. Sebaiknya hindari bahan pengujian yang nilainya bergantung pada waktu saat pengujian dijalankan; bekukan waktunya, atau hasilkan nilainya dari kunci tetap supaya dapat diulang kapan saja.

Untuk pengembang: menjaga fixture tetap sah

Perlakukan berkas fixture seperti kode: sertakan dalam peninjauan perubahan, dan tolak perubahan yang tidak dijelaskan alasannya. Bila ada nilai yang sengaja menyimpang dari aturan format, tuliskan alasannya di dekat nilai tersebut agar tidak ada yang memperbaikinya tanpa sengaja.

Tetapkan satu tempat sebagai rujukan bentuk data, lalu jalankan pemeriksaan ringan yang memastikan setiap catatan di dalam fixture masih mematuhi bentuk itu. Pemeriksaan seperti ini dapat dijalankan tanpa jaringan dan tanpa basis data, sehingga cukup murah untuk dijalankan setiap kali kode diperiksa.

Untuk nilai yang membutuhkan keragaman, pakai pembangkit dengan kunci tetap, lalu simpan kuncinya sebagai bagian dari pengujian, bukan nilai keluarannya. Dengan begitu, kegagalan tetap dapat diulang, sementara berkas yang harus dirawat tetap kecil. Cara menyusun kunci seperti ini sejalan dengan penjelasan pada pembahasan konsistensi data identitas, karena catatan yang tidak selaras akan tetap tidak selaras meski dibangkitkan berulang kali.

Akhirnya, ingat bahwa fixture tidak boleh menjadi tempat menyimpan rahasia. Kata sandi, kunci akses, dan token tidak pernah perlu berada di dalam bahan pengujian, dan menaruhnya di sana justru membuat pengujian sulit dipindahkan ke lingkungan lain.

Langkah berikutnya

Buka berkas bahan pengujian Anda dan tandai setiap catatan yang tidak jelas asalnya. Ganti catatan yang berasal dari data sungguhan dengan nilai dari generator data identitas, lalu kurangi jumlah catatan tersimpan menjadi hanya yang benar-benar mewakili kasus batas. Bila Anda ingin melihat bagaimana ketidakselarasan antar bidang muncul pada bahan semacam ini, bahasan lanjutannya ada pada catatan tetap dan konsistensi bidang, sedangkan pilihan antara menyimpan dan membangkitkan bahan uji dibahas lebih jauh di perbandingan data sintetis dan data teranonimkan.