Peningkatan Pengujian Unit Otomatis dengan Large Language Model oleh Meta

Alat Peningkatan Pengujian Unit Otomatis Meta: TestGen-LLM

• TestGen-LLM yang dikembangkan oleh Meta adalah alat yang secara otomatis meningkatkan pengujian yang dibuat manusia dengan menggunakan large language model (LLM).
• Kelas uji yang dihasilkan oleh TestGen-LLM berhasil melewati rangkaian filter yang menjamin peningkatan terukur dibandingkan suite uji asli, sehingga mengatasi masalah halusinasi LLM.
• Artikel ini menjelaskan penerapan TestGen-LLM dalam test-a-thons untuk platform Instagram dan Facebook milik Meta.

Evaluasi Kinerja TestGen-LLM

• Dalam evaluasi untuk fitur Reels dan Stories di Instagram, 75% kasus uji yang dihasilkan TestGen-LLM dibangun dengan benar, 57% lolos dengan andal, dan 25% meningkatkan cakupan.
• Dalam test-a-thon Instagram dan Facebook Meta, TestGen-LLM meningkatkan 11,5% dari semua kelas yang diterapkan, dan insinyur software Meta menerima 73% rekomendasi untuk diproduksi.
• Ini merupakan laporan pertama tentang rilis pada skala industri untuk kode yang dihasilkan LLM, dengan jaminan seperti ini pada perbaikan kode.

Pendapat GN⁺

• TestGen-LLM, yang berhasil meningkatkan pengujian yang sudah ada dengan memanfaatkan LLM, berpotensi menjadi inovasi penting dalam otomasi dan peningkatan kualitas pengujian perangkat lunak.
• Alat ini berkontribusi signifikan bagi komunitas rekayasa perangkat lunak dengan meningkatkan cakupan pengujian di lingkungan industri nyata dan menghasilkan kasus uji yang andal.
• Keberhasilan penerapan dalam test-a-thon Meta menunjukkan potensi integrasi TestGen-LLM ke dalam pengembangan produk nyata, yang merupakan kemajuan penting untuk meningkatkan efisiensi dan stabilitas pengembangan perangkat lunak.

[GN⁺]

Komentar Hacker News

• Sebuah perusahaan asuransi besar menetapkan target 80% cakupan tes untuk seluruh codebase. Akibatnya para pengembang mulai menulis unit test sederhana untuk getter dan setter DTO Java agar target itu tercapai. Sebagai pengembang muda, pengalaman ini membuat saya sadar bahwa jika terlalu fokus pada KPI, perilaku yang muncul bisa tidak selaras dengan tujuan yang diinginkan. Beberapa skenario pengujian E2E yang dirancang dengan baik kemungkinan besar memberi dampak lebih baik pada kualitas perangkat lunak.
• Masalah utama pengujian yang dihasilkan LLM adalah kemungkinan tinggi "menyetujui" perilaku yang memiliki bug. Hal ini terjadi terutama ketika coverage pengujian codebase masih rendah. Saat menulis tes baru secara manual, ada manusia yang bisa menentukan apakah sistem yang bodoh atau tes yang salah. Minimal, tes seperti ini sebaiknya dipisahkan ke folder test khusus dan diperlakukan dengan tingkat kecurigaan yang sesuai.
• Jika membaca PDF-nya, ini tampaknya sekadar menghasilkan tes yang terus-menerus lolos, alias tidak flaky. Tujuannya adalah membuat suite regression test untuk mengunci perilaku kode yang sudah ada. Ini bukan pengganti tes yang ditulis pengembang; tes yang ditulis pengembang diasumsikan memahami kebutuhan fungsional.
• Sekitar 20 tahun lalu, saya pernah bekerja di perusahaan yang sempat mencoba AgitarOne. Ini menjanjikan untuk secara otomatis menghasilkan test case untuk kode Java dan membantu menelusuri perilakunya. Namun Agitar juga dapat menghasilkan tes yang lolos secara otomatis, dan itu bisa dipakai sebagai regression suite. Secara pribadi saya tidak menyukainya. Manajer menganggap kualitas meningkat karena cakupan tes naik. Saya penasaran seberapa jauh pendekatan LLM ini lebih baik dibanding Agitar.
• Menulis tes umumnya merupakan cara bagus untuk menilai kualitas kode. Jika tesnya kompleks atau sulit mencapai cakupan, kemungkinan besar ada yang perlu diperbaiki dari kode yang dites.
• unlogged.io pernah cukup lama fokus membuat tes junit secara otomatis. Pendekatan ini tidak berhasil karena beberapa alasan: 1) terlalu banyak kode tes yang dihasilkan dan pengembang tidak mau memeliharanya, 2) tes yang dihasilkan tidak mensimulasikan skenario dunia nyata, 3) coverage sebagai metrik vanity. Saat ini kami fokus menyediakan no-code replay tests yang mensimulasikan semua skenario produksi yang unik. Perlu dicatat, saya adalah pendiri unlogged.io.
• Sebaliknya, saya ingin pendekatan sebaliknya: masukkan acceptance criteria, hasilkan tes yang memverifikasinya, lalu hasilkan kode yang hanya lolos lewat tes tersebut. Copilot kadang bisa mendekati itu dalam bentuk terbatas, tapi saya penasaran kenapa sepertinya tidak ada yang fokus ke arah ini.
• TestGen-LLM adalah kreasi yang aneh. Saya pikir ini bisa dipakai sebagai langkah awal untuk refactor atau rewrite, tetapi penekanan terhadap code coverage di paper-nya terasa benar-benar tidak masuk akal. Jika organisasi memang memangnya sudah gila sehingga menuntut coverage tinggi, mungkin baik. Tapi TestGen-LLM tidak akan memperbaiki kode proyek dengan cara apa pun dan malah meningkatkan gesekan saat mencoba melakukan perbaikan nyata. Alih-alih menggunakan error kompilasi dan tes yang gagal untuk menyaring "sampah" LLM, akan jauh lebih berguna jika TestGen-LLM menghasilkan tes edge case yang bisa lolos dan bisa juga gagal. Karena di paper tidak ada contoh tes yang dihasilkan, saya curiga tes-tesnya amatir seperti kode LLM lain yang pernah saya lihat.
• Saya penasaran berapa biaya masa depan untuk mempertahankan korpus besar tes yang dihasilkan otomatis. Tidak cukup sekadar menyediakan cara otomatis untuk membuat kasus; harus juga menyediakan cara otomatis untuk memperbaruinya.
• Menarik bahwa staf Meta menerbitkan paper 12 halaman untuk mempromosikan AI bagi pengembang. Mereka bahkan memakai sequence diagram. Mungkin saya salah, tetapi jika dipublikasikan seperti ini semestinya ada informasi yang bisa direproduksi. Karena Meta butuh data untuk melatih model, mungkin mereka memang perlu membagikan sesuatu.
• Dalam evaluasi terhadap produk Reels dan Stories Instagram, 75% test case TestGen-LLM dibangun dengan benar, 57% lolos secara andal, dan 25% meningkatkan cakupan. Hasilnya tampaknya tidak terlalu baik, ya?