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

• Di sebuah perusahaan asuransi besar tempat saya dulu bekerja, ketika manajemen menetapkan target cakupan pengujian 80% untuk seluruh codebase, orang-orang mulai menulis unit test yang tidak berguna untuk getter/setter DTO Java demi memenuhi target
  Tentu saja para developer juga tidak bisa mengubah aturan pengukuran coverage Sonar, dan saat masih developer junior saya belajar bahwa jika hanya melihat KPI, itu bisa mendorong perilaku yang tidak sesuai dengan maksud semula
  Beberapa skenario pengujian E2E yang dirancang dengan baik kemungkinan besar lebih baik untuk kualitas perangkat lunak

  • Pada codebase serupa, saya menyederhanakan secara besar-besaran logika ceroboh yang dibuat developer kurang berpengalaman, lalu mengajukan PR yang mengurangi codebase 20%, dan semua test serta kebutuhan pengguna juga lolos
    Masalahnya, kode lama yang berantakan itu sudah diuji dengan sangat baik dengan coverage 95%. Kode baru memiliki coverage 100%, tetapi karena jauh lebih pendek, coverage keseluruhan justru turun sehingga tidak lolos
    Kode yang tersisa hanyalah kode UI Swing yang sulit diuji dan makna pengujiannya juga tidak seberapa, jadi alih-alih menghabiskan 1–2 minggu menulis test Swing, tech lead membiarkan kode lama tetap ada di suatu tempat dalam repositori dan membuat test tetap menunjuk ke kode itu
    Akhirnya ribuan baris dead code yang tidak akan pernah dipanggil di produksi tetap tertinggal di repositori demi memuaskan Sonar
  • Pada magang pertama saya juga, manajemen memaksakan penggunaan alat kualitas kode, dan di dalamnya ada aturan “nonaktifkan magic number”
    Hasilnya, di header muncul hingga ribuan konstanta seperti static const unsigned ONE = 1;, TWO = 2;, THREE = 3;
  • Menurut saya solusinya adalah mutation testing. Bukan sekadar menjalankan kode untuk mengakali coverage, melainkan memaksa test benar-benar memverifikasi implementasi nyata
    https://en.m.wikipedia.org/wiki/Mutation_testing
    Hampir semua bahasa memiliki alat dan framework untuk ini; contohnya stryker-mutator(C#, TypeScript), pitest(Java), mutatest(Python)
  • Kami juga punya pemindaian Sonar wajib, dan saat saya bergabung, tech lead membanggakan peringkat “A” sambil berkata “kita punya standar tinggi yang harus dipertahankan”
    Selama 6 tahun berkarier, saya belum pernah melihat aplikasi seburuk itu; bukan hanya soal gaya, tetapi banyak bagian yang benar-benar rusak, dan tidak ada yang tahu apa yang salah
    Saya sangat tidak suka Sonar. Seharusnya dipakai hanya untuk pelaporan kerentanan, bukan untuk menyuruh mengganti nama variabel atau berkata “duplikasi kode ini harus direfaktor”. Kami sudah punya backlog tiket Jira, jadi jangan sampai alat itu juga mendikte apa yang harus dilakukan dan kapan
    Namun para manajer sangat menyukai alat permainan kekuasaan semacam ini
  • Ungkapan “Begitu sebuah metrik menjadi target, ia berhenti menjadi metrik yang baik” benar-benar tepat
    Masalah besarnya adalah mereka mewajibkannya, lalu jika ingin menghindari kebodohan, kita harus melewati prosedur birokrasi raksasa. Minggu lalu saja saya berdebat karena alat kualitas kode wajib mengeluh bahwa res.status(200).json() tidak memiliki header HSTS
    Meski disetel manual atau memakai app.use(helmet()), alat itu tetap mengeluh, dan pada akhirnya tampak seolah-olah ia ingin seluruh backend ditulis dalam satu file. Padahal HSTS justru ditangani dengan lebih elegan dan otomatis di ingress atau load balancer
    Saya bisa saja menandainya sebagai false positive lalu menghabiskan 1–2 minggu menjelaskan kepada manajer senior apa itu HSTS untuk mendapat persetujuan, tetapi akhirnya saya menambahkan res.sendJson(data, status = 200) ke prototype objek respons. Jelas ini implementasi bodoh, tetapi membuat saya sadar bahwa di bidang yang penuh birokrasi, perangkat lunak buruk terbentuk dari kumpulan implementasi buruk seperti ini

• Dari bagian yang menyebut “75% test case TestGen-LLM berhasil di-build, 57% lulus secara stabil, dan 25% meningkatkan coverage”, masalahnya adalah tes yang dihasilkan LLM tampaknya berpeluang besar “mengesahkan” perilaku yang mengandung bug
  Terutama jika codebase tersebut memang sudah memiliki coverage tes yang rendah. Jika manusia menulis tes baru secara langsung, keuntungannya adalah ada orang yang bisa menilai apakah sistemnya bodoh atau tesnya yang salah
  Minimal, tes seperti ini harus dipisahkan ke folder tes khusus dan diperlakukan dengan tingkat kecurigaan yang memadai

  • Menulis tes sebenarnya adalah kesempatan bagus untuk menemukan bug
    Namun codebase dengan coverage yang baik memungkinkan refactoring berskala besar dilakukan dengan aman tanpa regresi, dan itu tetap merupakan sifat yang berguna meskipun ada bug dan refactoring mempertahankan bug tersebut apa adanya
    Risiko dari alat pembuat tes yang dirancang untuk meng-encode perilaku saat ini adalah kita bisa terjebak dalam rasa aman palsu, padahal yang sebenarnya di-encode hanyalah perilaku saat ini
    Mungkin ini bisa diatasi dengan tidak menyebutnya “tes”, melainkan nama seperti “snapshot perilaku”. Namanya harus menyiratkan bahwa yang ditangkap adalah perilaku saat ini, bukan perilaku yang benar
  • Saya melihat ini sebagai salah satu contoh dari masalah perubahan yang tidak diinginkan yang lebih umum. Ketika ada sistem otomatis yang bisa mengubah dirinya sendiri, bagaimana kita tahu apakah suatu perubahan benar-benar perubahan yang dimaksudkan dan benar, atau justru gejala dari bug, kegagalan, atau pengetahuan otomasi yang tidak lengkap
    Karena itu, menurut saya selalu diperlukan semacam pengawasan manusia untuk menilai skenario mana yang terjadi
    Hal seperti ini terjadi di berbagai macam sistem, dan orang cenderung berpikir masalahnya bisa diselesaikan dengan menambahkan satu lapisan otomasi lagi, seperti di sini. Tes awalnya diciptakan untuk memastikan program berjalan dengan benar, tetapi jika itu pun diotomatisasi, kita akan bertemu masalah yang sama lagi dalam kode yang lebih besar, yakni dalam bentuk tes alih-alih assertion
  • Sebaliknya, pada codebase dengan coverage tes rendah dan masa kerja rata-rata engineer sekitar 1 tahun, menyiapkan kerangka tes awal itu sendiri bisa menjadi hambatan besar
    Ada kalanya kita tidak tahu bagaimana harus membuat factory untuk input tambahan yang dibutuhkan tes, tetapi tahu bagaimana kode itu sendiri seharusnya bekerja
    Jika LLM dapat menyiapkan kerangka tes dan memudahkan developer menulis verifikasi logika bisnis, itu bisa menjadi keuntungan besar
    Namun jika tes yang dihasilkan, seperti kebanyakan unit test, terlalu terikat pada implementasi, itu akan memperlambat kecepatan pengembangan. Jika tiap tes terlalu sulit diperbaiki, kita bahkan bisa melihat orang menghapus semua tes saat melakukan perubahan besar lalu membuatnya lagi
  • Pada sistem yang cukup besar, tes yang hanya mendeteksi perilaku yang berubah tetap bernilai, meskipun perilaku tersebut mengandung bug
    Sebagian kode mungkin bergantung pada bug itu, dan memperbaikinya, entah tanpa sengaja maupun sengaja, bisa menimbulkan masalah yang lebih serius
    Tentu saja tes seperti ini tidak bisa menggantikan tes yang memverifikasi requirement sebenarnya
  • Saya setuju bahwa pada proyek baru atau proyek yang sedang aktif dikembangkan, pembuatan tes otomatis kemungkinan besar adalah ide buruk
    Namun ada tak terhitung banyaknya sistem legacy yang sudah masuk mode maintenance dengan coverage rendah, dan dalam kasus seperti itu, pembuatan tes yang memverifikasi perilaku saat ini sangat berguna. Itu memungkinkan kita memastikan bagian lain tetap sama ketika seseorang melakukan perubahan

• Setelah membaca PDF-nya, ini tampaknya “sekadar” menghasilkan tes yang lulus berulang kali, yakni tes yang tidak flaky
  Tujuan utamanya adalah membuat kumpulan tes regresi berupa tes yang mengunci perilaku kode yang ada, bukan menggantikan tes developer yang ditulis dengan memahami requirement fitur
  Hampir 20 tahun lalu, perusahaan tempat saya bekerja juga pernah mencoba AgitarOne, yang menjanjikan pembuatan test case otomatis untuk mengeksplorasi perilaku kode Java. Selain itu, ia bisa membuat tes yang lulus hampir secara otomatis untuk digunakan sebagai kumpulan tes regresi
  Secara pribadi saya tidak menyukainya. Terlalu banyak artefak yang dihasilkan, dan manajemen memahami bahwa jika coverage naik maka kualitas juga naik. Saya penasaran seberapa jauh lebih baik pendekatan LLM yang dibicarakan FB di sini dibandingkan saat itu
  http://www.agitar.com/solutions/products/agitarone.html

  • Banyak unit test yang dibuat dengan cara seperti itu lebih menjadi pendeteksi perubahan daripada tes regresi. Ada perbedaan besar antara tes yang gagal ketika kode berubah dan tes yang gagal ketika bug diperkenalkan kembali
    Sampai LLM bisa menilai kebenaran nyata tanpa bergantung pada asumsi atau oracle bahwa tes yang baik adalah tes yang lulus, tampaknya sulit untuk sampai ke sana. Prompt-nya harus menyertakan ekspektasi perilaku dalam bentuk tertentu
  • Sistem juga bisa terkunci pada perilaku yang kebetulan muncul
    Nilai tes adalah memastikan hal-hal yang dipedulikan seseorang tidak rusak, bukan membekukan selamanya setiap perilaku edge case yang nyaris tidak dipakai dan hanya merupakan hasil dari implementasi tertentu

• Berdasarkan pengalaman, menulis tes biasanya merupakan cara yang sangat baik untuk menilai kualitas kode
  Jika tesnya rumit atau sulit mencapai coverage, besar kemungkinan kode yang diuji perlu diperbaiki

  • Testability kode memang merupakan tolok ukur yang baik untuk kualitas kode. Hal-hal yang membuat kode sulit diuji umumnya terkait dengan kode berkualitas rendah
    Kode dengan coupling rendah, cohesion tinggi, dan kompleksitas rendah seharusnya mudah di-unit-test

• Dalam evaluasi produk Reels dan Stories Instagram, disebutkan bahwa 75% test case TestGen-LLM berhasil di-build, 57% lulus secara stabil, dan 25% meningkatkan coverage
  Dalam acara pengujian Instagram dan Facebook milik Meta, mereka memperbaiki 11,5% dari seluruh class yang diterapkan, dan 73% rekomendasi disetujui oleh software engineer Meta untuk deployment produksi
  Saya tidak tahu apakah rasio ini bagus. Perlu membaca lebih lanjut apakah hal-hal yang tidak bisa diterima itu sekadar kesalahan kecil yang biasanya kita tangkap dalam code review, atau masalah serius. Jika seorang engineer manusia punya tingkat kegagalan 25%, tergantung jenis kegagalannya, ia mungkin tidak terlalu membantu
  Saya juga mempertanyakan apakah misi keseluruhan untuk mengotomatiskan pembuatan unit test bagi kode Android ini memang arah yang baik. Orang-orang TDD mungkin sedang gelisah di dalam kubur, atau di tempat tidur mereka di rumah. Meski begitu, saya kira mereka memang menambahkan catatan pembatas di belakang

  • Di Facebook ada banyak kode tanpa tes, dan tidak ada yang mendapat poin PSC karena memperbaiki hal seperti itu

• Di unlogged.io, fokus utama selama beberapa waktu adalah pembuatan otomatis pengujian JUnit, tetapi tidak terlalu berhasil karena beberapa alasan.
  Kode pengujian yang dihasilkan terlalu banyak sehingga developer tidak ingin memeliharanya, tidak mampu menyimulasikan skenario nyata, dan code coverage hanyalah metrik semu. Developer menemukan cara memutar untuk memenuhi target dengan skenario yang tidak bermakna.
  Sekarang kami sedang berupaya menyediakan pengujian replay no-code yang menyimulasikan semua skenario operasional unik, dan dapat diputar ulang secara lokal oleh developer sambil melakukan mocking terhadap dependensi eksternal.
  Sebagai catatan, saya pendiri unlogged.io.

• Saya ingin bergerak ke arah sebaliknya. Jika memasukkan kriteria penerimaan, saya ingin dibuatkan pengujian yang memverifikasinya, lalu setelah itu dibuatkan kode yang lolos pengujian tersebut.
  Dengan Copilot kadang bisa melakukan hal serupa secara terbatas, tetapi saya tidak tahu mengapa rasanya tidak ada yang fokus pada urutan ini.

• TestGen-LLM benar-benar produk yang aneh. Mungkin bisa dipakai sebagai langkah pertama untuk refactoring atau penulisan ulang, tetapi penekanan pada code coverage di makalahnya terasa seperti penilaian yang benar-benar keliru.
  Jika organisasi sudah rusak karena menuntut coverage tinggi, mungkin ini bisa berguna, tetapi TestGen-LLM tidak akan membuat kode proyek menjadi lebih baik dengan cara apa pun dan hanya akan menambah friksi dalam implementasi perbaikan nyata.
  Akan jauh lebih berguna jika menghasilkan pengujian edge case yang mungkin lolos atau mungkin tidak, tetapi TestGen-LLM bergantung pada penyaringan sampah LLM melalui error kompilasi dan pengujian yang gagal.
  Melihat tidak adanya contoh pengujian yang dihasilkan sama sekali di makalahnya, saya curiga hasilnya mungkin amatiran seperti kode buatan LLM lain yang pernah saya lihat sejauh ini.

  • Baru-baru ini saya harus me-refactor proyek yang sama sekali tidak punya pengujian, dan LLM yang secara otomatis membuat draf pengujian sangat membantu.
    Bahkan juga membantu memahami apa yang sebenarnya coba dilakukan oleh kode tersebut.

• Menarik bahwa para karyawan Meta menulis makalah 12 halaman untuk mempromosikan AI bagi developer, bahkan sampai memakai diagram Sankey.
  Saya bisa saja keliru, tetapi jika mempresentasikannya seperti ini, bukankah seharusnya mereka juga menyediakan informasi yang dapat direproduksi?
  Ini bukan teori konspirasi; hanya saja saya tidak punya data pada level yang digunakan Meta untuk pelatihan. Saya penasaran apakah mereka pernah membuka sesuatu.

  • Jika mirip dengan Google, kemungkinan akan sulit dibuka karena terlalu erat terikat pada infrastruktur internal dan monorepo.
  • Jika ini makalah FSE 2024, artefaknya sepertinya perlu menyertakan teori atau evaluasi formal.

• Saya penasaran berapa besar biaya untuk memelihara korpus pengujian otomatis raksasa yang dihasilkan ke depannya.
  Mereka harus menyediakan bukan hanya cara menghasilkan kasus pengujian, tetapi juga cara otomatis untuk memperbaruinya.