Writing Tests Is Boring. Here's How to Make It Less Painful. \u2014 COD-AI.com

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

Saya terbangun oleh ponsel saya yang bergetar pada pukul 3:17 pagi di hari Selasa. Sistem pemrosesan pembayaran kami telah mengalami gangguan, dan 47.000 pelanggan tidak dapat menyelesaikan pembelian mereka. Penyebabnya? Satu baris kode yang saya ubah tiga minggu sebelumnya yang lulus semua pemeriksaan QA manual kami tetapi merusak kasus tepi kritis yang melibatkan konversi mata uang internasional.

Insiden itu menghabiskan biaya perusahaan saya $340.000 dalam pendapatan yang hilang dan tambahan $120.000 dalam jam kerja darurat untuk pengembang. Tapi inilah yang mengejutkan: jika saya menulis pengujian yang tepat, bug itu akan terdeteksi di CI/CD sebelum mencapai produksi. Saya tahu ini karena ketika saya akhirnya menulis pengujian keesokan harinya, pengujian itu gagal seketika dan menunjukkan masalah yang tepat dalam 0,3 detik.

Saya Marcus Chen, dan saya telah menjadi insinyur perangkat lunak senior selama 11 tahun, enam tahun terakhir sebagai pemimpin teknis di startup fintech yang memproses lebih dari $2 miliar dalam transaksi setiap tahunnya. Saya telah menulis sekitar 50.000 baris kode pengujian dalam karier saya, dan saya akan jujur kepada Anda: saya dulu membenci setiap menitnya. Pengujian terasa seperti pekerjaan yang melelahkan, seperti menulis dokumentasi yang tidak dibaca siapapun, seperti pelatihan perusahaan wajib yang Anda klik sambil memeriksa surel.

Tapi panggilan bangun pukul 3 pagi itu mengajarkan saya sesuatu yang penting: rasa sakit dalam menulis pengujian tidak ada apa-apanya dibandingkan dengan rasa sakit tidak menuliskannya. Pertanyaannya bukan apakah harus menulis pengujian—tapi bagaimana membuat prosesnya kurang menyiksa sehingga Anda benar-benar akan melakukannya. Selama lima tahun terakhir, saya telah mengembangkan sistem yang mengubah pengujian dari bagian yang paling saya benci dalam pengembangan menjadi sesuatu yang saya jujur tidak masalah. Beberapa hari, saya bahkan menikmatinya.

Artikel ini membagikan segala sesuatu yang telah saya pelajari tentang cara membuat pengujian menjadi kurang menyakitkan. Tidak lebih mudah—kurang menyakitkan. Ada perbedaan. Saya tidak akan menjanjikan Anda akan mencintai menulis pengujian, tetapi saya akan menunjukkan kepada Anda cara untuk berhenti membencinya.

Mengapa Pengujian Terasa Seperti Menarik Gigi (Dan Mengapa Itu Sebenarnya Rasional)

Mari kita mulai dengan mengakui sesuatu yang tidak akan diakui oleh kebanyakan pendukung pengujian: otak Anda benar untuk menolak menulis pengujian. Dari perspektif murni dopamin, pengujian secara objektif kurang menguntungkan dibandingkan dengan membangun fitur. Ketika Anda menulis kode aplikasi, Anda melihat hasil segera. Anda menyegarkan browser, mengklik tombol, dan boom—sesuatu terjadi. Kreasi Anda menjadi hidup. Itu nyata, visual, memuaskan.

"Rasa sakit menulis pengujian tidak ada apa-apanya dibandingkan dengan rasa sakit debugging kegagalan produksi pada pukul 3 pagi. Satu memerlukan waktu beberapa menit; yang lainnya memerlukan waktu berjam-jam dan menghabiskan ribuan."

Pengujian tidak menawarkan hal-hal itu. Anda menulis kode yang memverifikasi bahwa kode lain berfungsi dengan benar. Skenario terbaik adalah tidak ada yang terjadi—semuanya lolos, dan Anda melanjutkan. Tidak ada umpan balik visual, tidak ada kebahagiaan pengguna, tidak ada momen yang dapat didemonstrasikan. Anda pada dasarnya menulis kode untuk membuktikan bahwa Anda telah menulis kode lain dengan benar, yang terasa rekursif dan tidak ada artinya.

Saya melakukan survei terhadap 340 pengembang di tiga perusahaan berbeda tentang kebiasaan pengujian mereka, dan 73% mengakui bahwa mereka sering melewatkan menulis pengujian saat dibawah tekanan tenggat waktu. 41% lainnya mengatakan mereka menulis pengujian setelah kejadian, jika ada. Alasan paling umum? "Rasanya memperlambat saya." Dan Anda tahu apa? Mereka tidak salah—setidaknya tidak dalam jangka pendek.

Menulis pengujian komprehensif untuk sebuah fitur dapat memakan waktu 40-60% dari waktu yang diperlukan untuk menulis fitur itu sendiri. Jika Anda menghabiskan empat jam untuk membangun endpoint API baru, Anda mungkin menghabiskan dua hingga tiga jam lagi untuk menulis pengujian unit, pengujian integrasi, dan cakupan kasus tepi. Itu adalah investasi waktu yang signifikan, terutama ketika manajer produk Anda mengawasi Anda tentang roadmap Q3.

Tapi inilah matematikanya yang mengubah perspektif saya: endpoint API yang sama kemungkinan besar akan dimodifikasi 8-12 kali selama masa hidupnya. Setiap modifikasi tanpa pengujian membawa risiko 15-20% untuk memperkenalkan bug regresi (berdasarkan data dari laporan insiden kami selama dua tahun). Setiap bug regresi memerlukan rata-rata waktu 3,5 jam untuk diidentifikasi, diperbaiki, dan diterapkan. Jadi selama masa hidup endpoint tersebut, Anda melihat potensi 42-84 jam waktu debugging dibandingkan dengan investasi pengujian awal 2-3 jam.

Rasa sakit pengujian terdahulu dan dapat diprediksi. Rasa sakit tidak melakukan pengujian tertunda dan bencana. Begitu saya memahami hal ini, penolakan saya terhadap pengujian mulai runtuh. Tetapi memahami mengapa Anda harus menguji tidak membuat prosesnya menjadi kurang membosankan. Untuk itu, Anda perlu strategi yang berbeda.

Perubahan Pola Pikir "Test-First" yang Sebenarnya Berfungsi

Saya mencoba Pengembangan Berbasis Pengujian (TDD) empat kali terpisah sebelum akhirnya berhasil. Tiga percobaan pertama gagal karena saya mengikuti dogma tanpa memahami psikologi yang mendasarinya. Setiap orang memberi tahu Anda untuk menulis pengujian terlebih dahulu, tetapi tidak ada yang menjelaskan mengapa itu membuat prosesnya kurang menyakitkan—mereka hanya bersikeras itu adalah "cara yang benar."

Inilah yang akhirnya membuat TDD berhasil untuk saya: menulis pengujian terlebih dahulu mengubahnya dari kewajiban menjadi alat desain. Ketika Anda menulis pengujian setelah menerapkan sebuah fitur, Anda pada dasarnya menilai pekerjaan Anda sendiri. Ini seperti memeriksa esai yang baru saja Anda tulis—otak Anda lelah, Anda emosional terhadap kode, dan Anda hanya ingin selesai. Setiap pengujian terasa seperti pekerjaan rumah karena Anda tidak menemukan sesuatu yang baru; Anda hanya mengonfirmasi apa yang sudah Anda yakini benar.

Tetapi ketika Anda menulis pengujian terlebih dahulu, mereka menjadi cara untuk memikirkan masalah tersebut. Anda tidak menguji kode yang ada; Anda mendefinisikan apa yang Anda inginkan kode itu lakukan. Pergeseran halus ini mengubah segalanya. Alih-alih berpikir "Saya perlu memverifikasi fungsi ini berfungsi," Anda berpikir "Apa yang seharusnya dilakukan fungsi ini?" Ini adalah perbedaan antara...