Data alamat untuk pengujian bukan sekadar beberapa baris contoh yang ditempel ke dalam berkas uji. Ia adalah bahan yang menentukan apakah pengujian Anda menemukan masalah atau justru menyembunyikannya. Alamat yang terlalu rapi membuat semua kasus lolos, sedangkan alamat yang acak membuat kegagalan sulit dijelaskan.
Artikel ini membahas cara menyusun kumpulan alamat uji yang dapat diulang, bebas dari data pribadi, dan cukup beragam untuk mencakup bentuk alamat dari berbagai negara.
Apa yang dimaksud dengan fixture dan mengapa isinya penting
Dalam pengujian perangkat lunak, fixture adalah kumpulan data tetap yang dipakai berulang kali oleh pengujian. Karena isinya tetap, hasil pengujian bisa dibandingkan antarwaktu: bila suatu hari berkas yang sama menghasilkan jawaban berbeda, ada perubahan perilaku yang baru masuk.
Bagi alamat, sifat tetap itu punya nilai khusus. Alamat menyentuh banyak bagian sistem sekaligus: validasi formulir, pengiriman ke layanan pihak ketiga, pencetakan label, perhitungan ongkos kirim, dan laporan per wilayah. Ketika satu alamat uji berubah diam-diam, Anda tidak lagi tahu bagian mana yang menyebabkan perbedaan hasil.
Masalah muncul ketika fixture disusun dari alamat yang kebetulan sedang ada di tangan penulisnya. Isinya mungkin bagus, tetapi tidak mewakili negara lain, tidak mencakup kasus batas, dan tidak ada yang tahu mengapa alamat tertentu dipilih. Fixture yang baik selalu punya alasan untuk setiap barisnya.
Mengapa alamat pelanggan asli tidak boleh dipakai?
Alamat pelanggan adalah data pribadi, dan memindahkannya ke lingkungan pengujian menimbulkan risiko yang tidak sebanding dengan manfaatnya. Lingkungan pengujian biasanya punya kendali akses yang lebih longgar, salinannya beredar di mesin pengembang, dan catatannya sering bertahan jauh lebih lama daripada yang diperkirakan.
Risiko lain adalah kebocoran melalui jalur sampingan. Nama pelanggan bisa dihapus, tetapi kombinasi nama jalan, nomor rumah, dan kode pos sering sudah cukup untuk menemukan orangnya. Data semacam itu juga mudah tersebar ke layanan pihak ketiga yang dipakai selama pengujian, dan jejaknya sulit ditarik kembali.
Karena itu kebiasaan yang benar adalah memakai data yang dibuat, bukan data yang disalin. Pembangkit alamat lokal seperti generator alamat palsu di situs ini dirancang untuk itu: seluruh kolom berasal dari satu wilayah yang sama sehingga konsisten, tetapi tidak ada satu pun yang merujuk pada penerima nyata. Batas pemakaian data semacam ini dibahas lebih jauh di panduan privasi data alamat.
Mengapa data yang bisa dibuat ulang lebih berguna untuk pengujian?
Data yang bisa dibuat ulang memberi dua hal sekaligus: keanekaragaman dan ketertelusuran. Anda bisa menghasilkan ratusan alamat untuk uji beban, lalu menyimpan beberapa di antaranya sebagai kasus tetap dengan alasan yang jelas.
Kuncinya adalah menyimpan kumpulan yang dipakai pengujian, bukan hasil pembangkit yang baru setiap kali dijalankan. Pengujian otomatis yang memakai data acak baru pada setiap jalan memang menguji lebih banyak kombinasi, tetapi kegagalannya sulit direproduksi. Pola yang lebih sehat adalah menggabungkan keduanya: sebagian kasus tetap untuk pengujian rutin, dan sebagian data acak untuk penyelidikan berkala.
Simpan juga asal-usul data itu. Mencatat negara, alasan pemilihan, dan tanggal pembuatan membuat orang berikutnya yang membaca berkas tersebut tidak perlu menebak.
Kasus batas yang layak selalu ada
Tidak semua fixture perlu panjang. Beberapa kasus berikut biasanya sudah cukup mewakili masalah yang paling sering muncul.
| Kasus | Alasan disimpan |
|---|---|
| Alamat paling sederhana | Menjaga jalur normal tetap bekerja |
| Jalan yang sangat panjang | Menguji pemotongan dan tata letak label |
| Negara tanpa kode pos | Menguji kolom yang memang boleh kosong |
| Karakter di luar alfabet Latin | Menguji penyandian dan tampilan huruf |
| Alamat dengan unit dan nama gedung | Menguji bidang tambahan dan urutan baris |
| Kode pos yang tidak cocok dengan kotanya | Menguji penolakan lintas bidang |
Tambahkan satu kasus negatif yang harus selalu ditolak, misalnya alamat dengan bidang wajib yang kosong. Kasus negatif yang berhasil ditolak membuktikan bahwa pemeriksaan masih aktif; bila suatu hari ia lolos, Anda tahu ada perubahan yang melemahkan validasi.
Bagaimana mengelompokkan dan menamai berkasnya
Kelompokkan berdasarkan negara terlebih dahulu, lalu berdasarkan skenario. Struktur seperti itu membuat penambahan negara baru cukup dengan menambah satu berkas, tanpa menyentuh berkas lain. Nama berkas sebaiknya menyebutkan negara dan tujuan pemakaiannya, bukan nama orang yang membuatnya.
Di dalam berkas, setiap kasus perlu punya penanda yang stabil agar bisa dirujuk oleh pengujian. Penanda itu juga berguna saat melaporkan kegagalan: pesan yang menyebut penanda kasus jauh lebih mudah ditindaklanjuti daripada pesan yang hanya menyebut nomor baris.
Jumlah kasus di dalam satu berkas sebaiknya dijaga tetap kecil. Berkas yang memuat ratusan alamat sulit ditinjau ketika ada perubahan, dan peninjauan justru bagian yang paling menentukan dalam memelihara fixture. Bila Anda membutuhkan volume besar untuk uji beban, hasilkan berkas terpisah yang ditandai sebagai data bervolume, dan jangan mencampurnya dengan kasus tetap yang dipakai pengujian rutin.
Untuk hubungan antarnegara dan wilayah di dalam fixture, pembahasannya ada di panduan kode negara dan kode wilayah. Masalah yang muncul ketika kolom-kolom dibuat terpisah tanpa memperhatikan keterkaitannya dibahas panjang di artikel tentang konsistensi antar-kolom pada data uji.
Catatan untuk pengembang: versi, penamaan, dan pemeriksaan
Perlakukan berkas fixture seperti kode: ia masuk ke sistem kendali versi, perubahannya ditinjau, dan setiap perubahan punya alasan. Hindari menyunting nilai di tengah berkas tanpa mencatat mengapa nilai itu berubah, karena pengujian yang gagal beberapa bulan kemudian akan sangat sulit dijelaskan.
Jalankan pemeriksaan konsistensi pada fixture itu sendiri, sebelum pengujian dijalankan. Periksa bahwa kota benar-benar berada di wilayah yang tercantum, bahwa kode pos sesuai pola negaranya, dan bahwa kolom yang seharusnya kosong memang kosong. Pemeriksaan ini murah, dan ia mencegah Anda mengejar bug yang sebenarnya berasal dari data.
Terakhir, jaga agar fixture tidak menjadi tempat sampah. Setiap kasus yang tidak lagi relevan sebaiknya dihapus atau diberi penanda alasan; kumpulan data yang membengkak tanpa pemeliharaan akan memperlambat pengujian dan menyamarkan kasus yang benar-benar penting.
Langkah berikutnya
Buka berkas fixture alamat yang Anda miliki sekarang, dan tandai kasus mana yang masih punya alasan jelas untuk dipertahankan. Bila ada yang berasal dari data pelanggan, ganti dengan hasil generator alamat dan simpan sebagai kasus tetap dengan penanda yang sama.