Ringkasan dalam 3 poin
- Sepakati satuan, masukan sah, dan hasil acuan sebelum meminta kode.
- Uji tepat di batas aturan, sedikit di atasnya, serta data tidak valid.
- Jalankan tes pada implementasi sebenarnya dan tinjau perubahan secara terpisah.
Hasil yang akan kamu buat
Tabel kasus ongkir pada batas aturan sebelum kode dijalankan.
Siapkan bahannya
- CSV kasus uji ongkir di artikel
- Aturan bisnis yang disepakati
Langkah yang bisa diikuti
- Tuliskan aturan dengan satuan dan contoh yang tidak ambigu.
- Tentukan masukan valid serta bentuk kesalahan yang diharapkan.
- Susun kasus biasa, batas bawah/atas, dan masukan tidak valid.
- Minta implementasi kecil lalu jalankan semua kasus pada kode tersebut.
- Tinjau hasil, perubahan kode, dan dampak integrasi sebelum menggunakannya pada sistem nyata.
Instruksi yang bisa kamu sesuaikan
Dari aturan ongkir dan CSV kasus yang saya berikan, susun expected output untuk setiap kasus batas sebelum melihat hasil program. Pisahkan masukan tidak valid dari pesanan valid. Jangan mengubah aturan agar mengikuti keluaran kode. Catat ketidaksesuaian untuk review.
Delapan kasus uji ongkir fiktif
Contoh buatan Nalarku
Aturan latihan: berat harus berupa bilangan bulat positif dalam gram. Hingga 1.000 gram dikenai Rp10.000. Setiap tambahan 1.000 gram atau bagiannya menambah Rp5.000. Nol, berat negatif, dan gram pecahan harus ditolak. CSV berisi hasil acuan, bukan fungsi siap produksi.
Implementasi harus memberi hasil sesuai tabel. Contoh penting: 1.001 gram dikenai Rp15.000. Pembulatan tambahan berat ke bawah akan menghasilkan biaya yang salah pada kasus ini.
| Berat (gram) | Hasil yang diharapkan |
|---|---|
| 1 | Rp10.000 |
| 1000 | Rp10.000 |
| 1001 | Rp15.000 |
| 2000 | Rp15.000 |
| 2001 | Rp20.000 |
| 0 | Tolak |
| -1 | Tolak |
| 1000.5 | Tolak |
Yang perlu diperiksa
- Apakah 1.000 dan 1.001 gram masuk kelompok tarif yang berbeda?
- Apakah input pecahan, nol, dan negatif ditolak secara jelas?
- Apakah hasil acuan ditulis terpisah dari implementasi yang diuji?
Yang perlu dipahami
Dokumentasi GitHub menyebut kode dan saran review Copilot dapat terlihat valid tetapi salah secara logika, sintaks, atau keamanan. Review AI juga dapat melewatkan masalah maupun mengajukan masalah yang sebenarnya tidak ada.
GitHub menganjurkan pemeriksaan dan pengujian kode yang dihasilkan. Latihan di bawah adalah contoh Nalarku untuk mengubah aturan tertulis menjadi kasus uji; ini tidak mengukur akurasi Copilot atau model tertentu.
Aturan perlu cukup jelas untuk menghasilkan jawaban acuan
Sebelum menulis fungsi, tentukan satuan masukan, jenis nilai yang diterima, pembulatan, dan perilaku saat masukan tidak valid. Ketidakjelasan pada bagian ini dapat menghasilkan dua implementasi berbeda yang masing-masing tampak masuk akal.
Pada latihan ongkir, berat berupa bilangan bulat positif dalam gram. Hingga 1.000 gram dikenai Rp10.000, lalu tambahan setiap 1.000 gram atau bagiannya menambah Rp5.000. Semua tarif tersebut fiktif dan tidak mewakili layanan pengiriman nyata.
Aturan “atau bagiannya” menentukan perilaku pada 1.001 gram. Tambahan satu gram sudah masuk kelompok tambahan, sehingga hasil acuannya Rp15.000. Jika kode membulatkan tambahan ke bawah, satu contoh pada 1.000 gram dapat tetap lulus sementara titik berikutnya salah.
Kasus batas mencari tempat perilaku berubah
Pasangan 1.000 dan 1.001 gram memeriksa peralihan pertama, sedangkan 2.000 dan 2.001 gram memeriksa peralihan berikutnya. Pengujian ini membantu memastikan aturan berlaku konsisten, bukan hanya cocok pada satu angka yang dipakai saat menulis kode.
Masukan nol, negatif, dan pecahan memeriksa bagian aturan yang menentukan nilai sah. Penolakan perlu jelas agar program tidak diam-diam mengubah masukan menjadi biaya yang terlihat wajar. Bentuk kesalahan yang dikembalikan juga perlu sesuai kebutuhan pemanggil fungsi.
Delapan kasus pada CSV adalah titik awal. Keadaan lain seperti nilai yang hilang, jenis data yang keliru, atau batas ukuran memerlukan keputusan spesifikasi tersendiri. Menambah kasus perlu mengikuti risiko dan jangkauan fungsi, bukan hanya mengejar banyaknya baris pengujian.
Tes yang menyalin logika program dapat mengulang kesalahan
Hasil acuan sebaiknya ditulis dari aturan yang sudah disepakati. Jika tes menghitung jawaban memakai rumus yang sama dengan implementasi, satu kesalahan penalaran dapat muncul di keduanya. Tes terlihat lulus tetapi belum memeriksa asumsi yang keliru.
Untuk contoh kecil, perhitungan manual pada titik batas membantu memberi pembanding yang independen dari susunan kode. Simpan alasan mengapa tiap hasil diharapkan. Saat implementasi diubah, peninjau masih dapat melihat hubungan antara kasus dan aturan yang diuji.
GitHub mengingatkan bahwa saran kode dapat terlihat valid tetapi salah, dan review AI dapat melewatkan masalah atau memberikan temuan keliru. Penjelasan model perlu dibaca bersama perubahan kode serta hasil pengujian pada implementasi yang sebenarnya.
Perbaikan perlu diuji bersama dampak di sekitarnya
Ketika AI mengusulkan perubahan, tanyakan aturan mana yang diperbaiki dan kasus mana yang sebelumnya gagal. Jalankan kembali pemeriksaan yang relevan, kemudian baca perubahan untuk melihat dampak pada masukan lain atau bagian aplikasi yang memanggil fungsi.
Keberhasilan fungsi perhitungan juga belum menjawab seluruh integrasi. Antarmuka perlu mengirim satuan yang benar, menyampaikan kesalahan dengan jelas, dan menampilkan biaya sesuai hasil yang disetujui. Alur dari masukan sampai keluaran pengguna mempunyai bagian pemeriksaan tambahan.
Panduan ini menyediakan aturan dan hasil acuan, bukan fungsi siap produksi atau evaluasi akurasi suatu model. Untuk tarif nyata, zona, batas berat, dan ketentuan lain perlu ditulis secara spesifik. Pemisahan antara aturan, kode, dan bukti uji membuat perubahan lebih mudah dipertanggungjawabkan.
Jadikan aturan yang disepakati sebagai acuan pengujian
Kode perlu dinilai dari perilakunya terhadap aturan, termasuk pada titik perubahan dan masukan yang tidak sah. Dengan menulis hasil acuan lebih dahulu, developer mempunyai dasar untuk membaca usulan AI dan menemukan ketidaksesuaian. Kelancaran penjelasan atau keberhasilan satu contoh belum menunjukkan seluruh fungsi sudah benar.
Sumber dan referensi
Analisis menggabungkan fakta bersumber dan penafsiran Nalarku.
Naskah diperbarui 8 November 2026 pukul 19.47 WIB. Tanggal terbit pertama dipertahankan.
Proses editorial dan penggunaan AI · Hubungi Nalarku untuk koreksi
