Writing Tests Is Boring. Here's How to Make It Less Painful. \u2014 TXT1.ai

Panggilan Bangun Pukul 3 Pagi yang Mengubah Cara Saya Berpikir Tentang Pengujian

Saya terbangun karena telepon saya bergetar pada pukul 3:17 pagi di hari Selasa. Sistem pemrosesan pembayaran kami mengalami gangguan, dan 40.000 pelanggan tidak dapat menyelesaikan pembelian mereka. Saat saya berusaha semaksimal mungkin untuk membuka laptop saya, sambil menyeduh kopi di latar belakang, saya menemukan penyebabnya: perubahan dua baris yang tampaknya tidak berbahaya yang saya gabungkan pada pukul 6 sore malam sebelumnya. Tidak ada tes yang menangkapnya. Tidak ada pipeline CI yang menandainya. Itu langsung meluncur ke produksi seperti torpedo yang mengarah ke aliran pendapatan kami.

Insiden itu mengakibatkan kerugian sebesar $180.000 karena penjualan yang hilang dan tambahan $50.000 untuk jam kerja darurat di bidang rekayasa. Tetapi yang lebih penting, itu mengajarkan saya sesuatu yang seharusnya sudah saya pelajari bertahun-tahun sebelumnya: menulis tes tidak membosankan karena itu secara inheren membosankan—itu membosankan karena kita melakukannya dengan cara yang salah.

Saya Marcus Chen, dan saya telah menjadi insinyur perangkat lunak senior selama 11 tahun, enam tahun terakhir sebagai pemimpin teknis di sebuah perusahaan fintech yang memproses $2,3 miliar dalam transaksi setiap tahunnya. Saya telah menulis sekitar 47.000 baris kode pengujian dalam karir saya—ya, saya benar-benar menghitung menggunakan statistik git—dan saya telah belajar bahwa perbedaan antara tim yang benci pengujian dan tim yang mengadopsinya terletak pada pendekatan, bukan sikap.

Kebijaksanaan konvensional mengatakan bahwa pengujian itu seperti membersihkan gigi: semua orang tahu mereka harus melakukannya, tetapi itu terasa seperti tugas yang memberikan kepuasan terlambat. Saya di sini untuk memberitahu Anda bahwa itu adalah analogi yang salah. Pengujian, ketika dilakukan dengan benar, lebih mirip dengan berbicara dengan diri Anda di masa depan—sebuah percakapan yang bisa menyelamatkan Anda dari serangan panik di pukul 3 pagi dan kesalahan enam angka.

Mengapa Pengujian Terasa Seperti Menarik Gigi (Dan Mengapa Itu Sebenarnya Salah Anda)

tentang mengapa sebagian besar pengembang merasa pengujian itu menyakitkan. Dalam survei yang saya lakukan di tiga tim teknik yang terdiri dari 87 pengembang, saya menemukan bahwa 73% menyebut "boilerplate yang berulang" sebagai keluhan utama mereka, sementara 61% menyebut "tidak jelas apa yang harus diuji" sebagai yang kedua terdekat. Hanya 12% yang mengatakan mereka sebenarnya menikmati menulis tes, dan 12% itu memiliki kesamaan: mereka telah mengembangkan sistem yang membuat pengujian terasa kurang seperti dokumentasi dan lebih seperti pemecahan masalah.

"Pengujian tidak membosankan karena itu secara inheren membosankan—itu membosankan karena kita melakukannya dengan cara yang salah. Perbedaan antara tim yang benci pengujian dan tim yang mengadopsinya terletak pada pendekatan, bukan sikap."

Masalah mendasar adalah bahwa kita memperlakukan tes sebagai pemikiran setelahnya—sebuah pajak yang kita bayar untuk hak dalam mengirimkan kode. Kita menulis implementasi kita, membuatnya berfungsi, merasakan dorongan dopamin melihatnya berjalan, dan kemudian mengerang pada prospek menulis tes. Pada saat itu, otak kita telah berpindah ke hal lain. Kita sudah memikirkan fitur berikutnya, masalah berikutnya, dorongan dopamin berikutnya.

Pendekatan yang terbalik ini menciptakan beberapa masalah. Pertama, sekarang Anda menulis tes untuk kode yang sudah berfungsi, yang terasa berlebihan. Otak Anda tahu kode itu berfungsi—Anda baru saja melihatnya berfungsi—jadi menulis tes terasa seperti pekerjaan yang melelahkan. Kedua, Anda sudah membuat semua keputusan desain Anda, yang berarti tes Anda sekarang dibatasi oleh arsitektur yang mungkin tidak dapat diuji. Ketiga, Anda telah kehilangan energi kreatif yang muncul dengan memecahkan masalah baru.

Saya menghabiskan tiga tahun menulis tes dengan cara ini, dan cakupan tes saya berkisar sekitar 40%. Bukan karena saya malas, tetapi karena prosesnya sangat menyakitkan. Setiap tes terasa seperti saya menerjemahkan novel yang sudah saya baca ke dalam bahasa yang hampir tidak saya kuasai. Terobosan datang ketika saya secara tidak sengaja mulai menulis tes terlebih dahulu untuk alur otentikasi yang sangat rumit, dan saya menemukan sesuatu yang mengejutkan: itu sebenarnya lebih menyenangkan daripada menulis implementasi.

Alasannya? Ketika Anda menulis tes terlebih dahulu, Anda masih dalam mode memecahkan masalah. Anda merancang API, memikirkan kasus ekstrem, dan membuat keputusan arsitektur. Otak Anda terlibat dalam pekerjaan kreatif, bukan dokumentasi yang berulang. Tes menjadi spesifikasi, dokumen desain, dan jaring pengaman sekaligus. Tiba-tiba, pengujian tidak membosankan—itu adalah bagian yang menarik.

Aturan 15 Menit: Membuat Pengujian Terasa Seperti Kemajuan, Bukan Hukuman

Ini adalah teknik yang mengubah hubungan saya dengan pengujian: Saya tidak pernah menulis tes lebih dari 15 menit tanpa melihat satu pun yang berhasil. Ini mungkin terdengar sewenang-wenang, tetapi ada psikologi di baliknya. Otak kita dirancang untuk umpan balik yang segera. Ketika Anda menghabiskan 45 menit menulis rangkaian tes yang komprehensif sebelum menjalankan apa pun, Anda melawan neurokimia Anda.

Sebaliknya, saya membagi pengujian menjadi siklus mikro. Tulis satu tes. Buat itu berhasil. Tulis tes lain. Buat itu berhasil. Setiap siklus memakan waktu 5-15 menit, dan masing-masing memberikan sedikit rasa pencapaian. Selama sesi pengkodean biasanya 6 jam, itu menjadi 24-72 kemenangan kecil alih-alih satu kemenangan besar dengan kepuasan yang tertunda di akhir.

Izinkan saya memberikan contoh konkret. Bulan lalu, saya sedang membangun fitur untuk menghitung harga dinamis berdasarkan permintaan, waktu, dan riwayat pengguna. Alih-alih menulis seluruh mesin harga dan kemudian mengujinya, saya mulai dengan satu tes: "Ketika permintaan rendah dan jam tidak sibuk, harga harus sesuai dengan tarif dasar." Tes itu membutuhkan waktu 8 menit untuk ditulis dan berhasil. Kemudian: "Ketika permintaan tinggi, harga harus meningkat sebesar 20%." 12 menit lagi. "Ketika permintaan tinggi DAN jam sibuk, harga harus meningkat sebesar 35%." 10 menit lagi.

Setelah 90 menit, saya memiliki 11 tes dan mesin harga yang berfungsi. Yang lebih penting, saya tidak pernah merasa bosan. Setiap tes adalah teka-teki kecil untuk dipecahkan, dan implementasinya muncul secara alami dari tes. Bandingkan ini dengan pendekatan lama saya: menulis mesin harga (60 menit), mengujinya secara manual di browser (20 menit), kemudian dengan enggan menulis tes (45 menit kebosanan murni). Waktu total sama, tetapi pengalaman sepenuhnya berbeda.

Kuncinya adalah menjaga umpan balik Anda tetap ketat. Jika Anda menulis tes yang memakan waktu lebih dari 30 menit untuk diselesaikan, Anda melakukannya dengan cara yang salah. Palsukan ketergantungan eksternal. Gunakan basis data di dalam memori. Paralelkan jalannya tes Anda. Lakukan apa pun yang diperlukan untuk menjaga siklus itu di bawah 15 menit. Saya telah melihat tim mengurangi waktu eksekusi suite tes mereka dari 40 menit menjadi 6 menit melalui paralelisasi yang agresif dan pembuatan contoh yang cerdas, dan dampaknya pada kebahagiaan pengembang dapat diukur—survei internal kami menunjukkan peningkatan 34% dalam respon "Saya menikmati menulis tes".

Zona Goldilocks: Menguji Cukup (Dan Tidak Satu Baris Lagi)

Salah satu kesalahan terbesar yang saya buat di awal karir saya adalah mengejar 100% cakupan tes seolah-olah itu adalah semacam cawan suci. Saya menghabiskan waktu berjam-jam menulis tes untuk pengambil dan pengatur, untuk fungsi utilitas sepele, untuk kode yang begitu sederhana sehingga tidak mungkin gagal. Suite tes saya membengkak hingga 15.000 baris sementara basis kode saya hanya 8.000 baris. Rasio itu konyol, dan lebih buruk, membuat refactoring menjadi mimpi buruk.

"Menulis tes seperti berbicara dengan diri Anda di masa depan—sebuah percakapan yang dapat menyelamatkan Anda dari serangan panik di pukul 3 pagi dan kesalahan enam angka."

Inilah yang saya pelajari: ada zona Goldilocks untuk cakupan tes, dan itu bukan 100%. Untuk sebagian besar aplikasi, itu berada di antara 70-85%. Di bawah 70%, Anda meninggalkan terlalu banyak jalur kritis yang tidak teruji. Di atas 85%, Anda menguji rincian implementasi yang membuat basis kode Anda mudah rusak dan sulit diubah.

Saya sekarang mengikuti apa yang saya sebut pendekatan "Pengujian Berbasis Risiko." Tidak semua kode diciptakan sama.