Berasal dari latar belakang analitik & ilmu data, saya dulu melihat tes menulis sebagai sesuatu yang menyakitkan. Saya tahu itu penting, tetapi saya tidak pernah tahu harus mulai dari mana dan selalu menunda sampai akhir proyek. Apa yang lebih membosankan daripada menguji sepotong kode yang sudah berfungsi?

Baru-baru ini, saya mulai melihat hal-hal sebaliknya. Saya menemukan Test-Driven Development: tulis pengujian Anda sebelum Anda benar-benar membuat kode bagian fungsional dari kode tersebut. Ini adalah praktik terbaik dalam rekayasa perangkat lunak yang pantas diterapkan lebih sering pada proyek ilmu data.

Apa itu Test-Driven Development (TDD)?

Sebuah cara sederhana untuk menjelaskannya adalah melalui kerangka Red/Green/Refactor . Setiap kali Anda ingin menambahkan fungsionalitas ke kode, Anda dapat mengikuti siklus tiga langkah:

1. Merah . Buat tes yang gagal. yaitu menulis kebutuhan fungsional kode Anda
2. Hijau . Tulis kode produksi yang membuat tes lulus. yaitu memenuhi kebutuhan fungsional kode
3. Refaktor. Bersihkan kekacauan yang baru saja Anda buat. yaitu bersihkan kode Anda tanpa mengubah fungsionalitasnya

Mari kita ilustrasikan ini dengan contoh kehidupan nyata. Sebagai langkah pasca-pemrosesan untuk proyek Pengenalan Entitas Bernama , kami ingin membuat fungsi pemrosesan untuk mengekstrak unit durasi (hari/minggu/bulan/..) dan nilai durasi dalam teks.

1. Mari tulis pengujian unit yang memenuhi kebutuhan fungsional dan fungsi kosong.

2. Kami menulis kode yang lulus ujian.

Ujiannya HIJAU Hore !! Tunggu dulu.. yakin KERING, PADAT, pep8??

3. Kami memfaktorkan ulang fungsi, untuk memastikan praktik pengkodean terbaik.

Di sini kami menambahkan anotasi jenis, membuat fungsi generik untuk mengonversi nomor huruf menjadi float (dengan pengujian unitnya sendiri juga) dan memfaktorkan ulang cara kami mengisi kamus.

Di mana kita dapat menerapkan Pengembangan Berbasis Tes dalam Ilmu Data?

Test Driven Development tidak relevan di setiap langkah proyek ilmu data. Misalnya, tidak ada gunanya selama eksplorasi data atau model di mana Anda tidak yakin dengan apa yang Anda cari: menulis tes tanpa mengetahui hasil yang diharapkan mungkin berlebihan.

Ini menjadi sangat berguna kapan pun Anda perlu membangun jaringan pipa produksi yang kuat .

Dalam konteks ini, kita perlu mengimplementasikan beberapa jenis pengujian:

• Tes unit: tes untuk setiap potongan kode proyek
• Tes model : memastikan bahwa model memiliki kinerja yang baik dan berperilaku dengan benar
• Tes integrasi : memastikan bahwa ada hubungan yang baik antara setiap bagian kode

Untuk tes model , itu harus digunakan dengan hati-hati. Saat berhadapan dengan model prediktif, kita berhadapan dengan ketidakpastian . Memang, banyak algoritme pembelajaran mesin secara inheren acak — banyak proses yang menggunakan input yang sama dapat menghasilkan hasil yang sedikit berbeda setiap saat. Hal ini dapat menyebabkan pengujian yang tidak stabil : pengujian yang terkadang lolos dan terkadang gagal meskipun tidak ada perubahan pada kode atau pengujian itu sendiri. Jika kami terlalu spesifik pada kasus pengujian selama pengembangan pertama yang digerakkan oleh pengujian, kemungkinan besar beberapa pengujian akan berhenti pada iterasi berikutnya. Model baru dapat berperilaku berbeda dalam beberapa kasus, sekaligus berperforma lebih baik secara global. Oleh karena itu, lebih baik memasukkan dalam pengujian model hanya kasus dasar yang diperlukan untuk proyek.

Terakhir untuk tes integrasi , ini berlaku baik untuk potongan kode yang tidak menyertakan prediksi model. Jika termasuk prediksi model, lebih baik untuk menguji format keluaran daripada keluaran aktual.

Praktik yang baik adalah memasukkan pengujian tersebut ke dalam CI/CD proyek Anda. Oleh karena itu setiap kali proposal fungsionalitas baru dibuat, dipastikan tidak ada fungsionalitas lain yang rusak.

Mengapa ini mengubah permainan?

Mengadopsi Pengembangan Berbasis Tes benar-benar mengubah cara Anda mengatur sesi pengkodean dan ada banyak manfaatnya:

• Ini langsung memvalidasi bisnis dan spesifikasi teknis . Ini juga merupakan dokumentasi yang bagus untuk ilmuwan data yang menemukan proyek dan perlu memahami cara kerja proyek.
• Ini memberi kepercayaan pada kode . Setiap kasus penggunaan dicakup oleh pengujian dan Anda atau rekan satu tim Anda dapat menambahkan fungsionalitas tambahan tanpa takut merusak apa pun yang sudah dilakukan.
• Menghemat waktu . Seseorang dapat melihatnya sebagai sesuatu yang memperlambat perkembangan. Tapi ternyata tidak, ini memaksa Anda untuk memikirkan terlebih dahulu kebutuhan fungsional dan mengantisipasi kasus-kasus ekstrem. Percayalah, pada akhirnya, ini menghemat banyak waktu debugging dan iterasi.
• Itu bahkan membuat pengembangan lebih menyenangkan ! Itu memecah kode menjadi tantangan pemecahan masalah kecil . Dan itu sangat cocok untuk peer coding ..