Menguji aplikasi yang dihasilkan chat: apa yang dites pertama dan yang bisa dilewatkan

Mengapa aplikasi yang dihasilkan chat rusak di tempat yang bisa diprediksi

Codebase yang dibangun oleh chat cenderung gagal di tempat yang sama karena kode sering disusun dari potongan-potongan yang terlihat benar tetapi belum pernah dipaksa untuk saling cocok. Sebagian besar fitur bekerja di jalur bahagia (happy path), lalu rusak ketika pengguna nyata mengklik lebih cepat, mengirim input aneh, atau menggunakan versi klien yang lebih lama.

Banyak risiko berada di glue code: potongan kecil yang menghubungkan layar ke panggilan API, memetakan respons API ke state UI, dan mengubah input pengguna menjadi tulisannya ke database. Bagian-bagian ini membosankan, jadi mendapat perhatian lebih sedikit, padahal mereka mengendalikan alur seluruh aplikasi.

Regresi juga mengelompok di sekitar boundary di mana dua komponen harus berbagi kontrak. UI mengharapkan satu bentuk, API mengembalikan bentuk lain. API mengasumsikan database akan menerima sebuah nilai, lalu sebuah constraint menolaknya. Atau satu lapis mengubah penamaan, tipe, atau default dan lapisan lain tidak mengikuti.

Titik kegagalan yang sama muncul berulang kali:

• Tepian state UI (loading vs empty vs error, double clicks, tombol back, cache kadaluarsa)
• Celah validasi API (field hilang, tipe salah, enum tak terduga, cek auth/role)
• Penulisan ke database (penanganan null, unique constraint, transaksi, update parsial)
• Masalah waktu dan urutan (retry, race condition, alur “create lalu fetch”)
• Mismatch serialisasi (tanggal, ID, field opsional, nama field antar lapis)

Kecepatan membuatnya lebih tajam. Platform seperti Koder.ai mendorong iterasi cepat: Anda prompt, regenerate, refactor, lalu lanjut. Itu kekuatan. Namun juga berarti perubahan kecil terjadi sering, dan peluang untuk mematahkan sebuah boundary meningkat. Saat Anda mengirim cepat, Anda butuh tes yang berjalan cepat dan gagal lantang.

Tujuannya adalah kepercayaan, bukan kesempurnaan. Anda tidak mencoba membuktikan setiap baris benar. Anda berusaha menangkap perubahan yang akan memalukan Anda di produksi: form yang tidak lagi menyimpan, API yang mulai menolak request valid, atau update database yang diam-diam berhenti menulis sebuah field.

Ekspektasi sederhana membantu: lindungi kontrak dan jalur pengguna teratas terlebih dahulu. Semuanya bisa menunggu sampai terbukti menyakiti.

Cara 80/20 untuk memilih apa yang dites pertama

Dengan kode yang dihasilkan chat, risiko terbesar biasanya bukan kompilasi. Risiko itu adalah perubahan kecil yang merusak perilaku yang Anda anggap jelas.

Mulailah dengan menamai risiko teratas Anda dalam bahasa yang sederhana. Jika sebuah bug mengenai salah satu dari ini, biayanya cepat jadi besar:

• Uang (harga, pembayaran, kredit, metering)
• Permissions (siapa yang bisa melihat atau mengubah apa)
• Kehilangan data (hapus, overwrite, migrasi, rollback)
• Ketersediaan (login, halaman inti, endpoint API kunci, timeout)

Selanjutnya, pilih set tes terkecil yang mencakup alur pengguna nyata dan kontrak API di bawahnya. Aturan yang baik: satu happy path plus satu kasus “input buruk” untuk setiap alur inti. Contoh: “create item” harus menguji sukses dan kegagalan validasi (field wajib hilang), karena keduanya sering rusak ketika prompt berubah.

Lalu putuskan apa yang harus ditangkap sebelum merge vs sebelum rilis. Sebelum merge harus cepat dan dipercaya. Sebelum rilis bisa lebih lambat dan lebih luas.

Skala prioritas sederhana menjaga debat pendek:

• P0 (harus dites): menghalangi merge jika gagal
• P1 (sebaiknya dites): dijalankan di CI, tapi bisa diperbaiki dalam sehari
• P2 (bagus untuk dimiliki): dijalankan terjadwal atau saat refactor

Contoh konkret: fitur “Ganti password” di app React dengan Go API dan klien Flutter.

P0: API menolak password lemah, API memperbarui hash yang disimpan, dan kedua klien menampilkan pesan error saat gagal.

P1: rate limiting dan session expiry.

P2: state UI pixel-perfect.

Jika Anda menguji aplikasi yang dihasilkan chat (termasuk proyek yang dibangun di alat seperti Koder.ai), lensa 80/20 ini membantu Anda menghindari puluhan tes rapuh yang tetap melewatkan kegagalan yang benar-benar dirasakan pengguna.

Unit test React yang menangkap sebagian besar regresi

Regresi React biasanya datang dari dua tempat: kesalahan logika kecil (pembentukan data, validasi) dan state UI yang tidak sesuai kenyataan (loading, error, tombol disabled). Mulailah dari tempat di mana kegagalan menyakiti pengguna.

Mulai dengan logika murni (murah, sinyal tinggi)

Jika sebuah fungsi punya input dan output jelas, uji itu sebelum UI mana pun. Tes ini cepat, jarang flaky, dan melindungi dari perubahan satu baris yang merusak banyak hal.

Target awal yang baik: formatter tanggal dan mata uang, validator field, memetakan respons API ke view model, serta reducer atau mesin state yang menggerakkan layar.

Setelah itu, tulis beberapa tes komponen untuk layar yang dipakai orang untuk menyelesaikan pekerjaan. Daripada banyak snapshot dangkal, gunakan sejumlah kecil tes yang bertindak seperti pengguna: ketik di form, klik tombol, dan asert apa yang pengguna lihat.

Fokus pada state UI yang sering rusak: validasi form dan perilaku submit, state disabled (termasuk pencegahan double-submit), loading dan retry, rendering error, serta state kosong vs hasil.

Untuk apa pun yang berbicara ke jaringan, mock di boundary. Perlakukan client API Anda sebagai seam: asert bentuk request (method, path, query param kunci, dan payload), lalu berikan respons realistis kembali ke komponen. Ini menangkap drift kontrak lebih awal, terutama saat backend sering digenerate atau diedit.

Satu aturan yang terus berbuah: setiap kali Anda memperbaiki bug, tambahkan satu tes yang akan gagal jika bug itu kembali. Contoh: jika halaman yang digenerate Koder.ai pernah mengirim userId bukannya id, tambahkan tes yang memverifikasi kunci payload keluar sebelum melanjutkan.

Unit test Go API yang memberi hasil cepat

Handler Go bisa terlihat benar sementara menyembunyikan celah logika kecil yang berubah jadi bug nyata. Kemenangan tercepat datang dari tes yang mengunci input, permission, dan aturan yang memutasi data.

Apa yang dikunci dulu

Mulailah dengan validasi request. Kode yang dihasilkan chat mungkin menerima string kosong, mengabaikan panjang maksimum, atau menerapkan default yang salah. Tulis tes yang memanggil handler (atau fungsi validasinya) dengan payload buruk dan asert respons 400 yang jelas dengan error yang berguna.

Selanjutnya, kunci auth dan permission di edge. Regresi umum adalah “auth ada, tapi role yang salah masih bisa update.” Uji happy path dan beberapa kasus forbidden dengan membangun request dengan konteks user dan memanggil handler atau middleware.

Kemudian fokus pada aturan bisnis yang memutasi data. Create, update, delete, dan endpoint idempotent (seperti “create if not exists”) layak mendapat tes ketat. Ini tempat di mana refactor kecil bisa tak sengaja memungkinkan duplikat, melewatkan transisi state yang dibutuhkan, atau menimpa field yang harusnya immutable.

Jadikan pemetaan error eksplisit. API Anda harus menerjemahkan kegagalan umum secara konsisten ke status code yang tepat: bad input (400), not found (404), conflict (409), dan error tak terduga (500). Unit test harus mengasert baik status maupun bentuk error yang stabil agar klien tidak rusak.

Pengecekan High-ROI yang harus ditutup awal: field wajib dan default, cek permission per role, idempotency, dan pemetaan bersih antara kegagalan umum dan status code.

Table-driven tests menjaga edge case tetap terbaca:

tests := []struct{
  name string
  body string
  wantStatus int
}{
  {"missing name", `{"name":""}`, 400},
  {"too long", `{"name":"aaaaaaaaaaaaaaaa"}`, 400},
}

Unit test Flutter yang mencegah kejutan di sisi klien

Bug Flutter di aplikasi yang dihasilkan chat sering muncul dari asumsi kecil di klien: sebuah field kadang null, tanggal datang dalam format berbeda, atau layar yang macet di loading setelah retry. Beberapa tes fokus bisa menangkap sebagian besar masalah ini sebelum jadi tiket support.

Mulailah dengan pemetaan data. Risiko terbesar adalah boundary antara JSON dan model Dart Anda. Tulis tes yang memasukkan payload yang terlihat nyata ke fromJson dan pastikan Anda menangani field yang hilang, kunci yang diganti nama, dan nilai aneh. Enum dan tanggal biasanya bermasalah: nilai enum baru tidak boleh menjatuhkan aplikasi, dan parsing harus gagal dengan aman (dengan error jelas) alih-alih diam-diam menghasilkan nilai salah.

Selanjutnya, uji transisi state. Entah Anda menggunakan BLoC, Provider, Riverpod, atau setState sederhana, kunci apa yang pengguna alami setiap hari: load pertama, refresh, error, dan retry. Tes ini murah dan menangkap masalah “berputar selamanya” dengan cepat.

Set singkat yang cenderung memberi hasil:

• Parsing model untuk 2–3 objek inti (termasuk enum unknown, null, dan parsing tanggal/angka)
• Transisi view-model atau bloc (loading -> success, loading -> error, error -> retry -> success)
• Aturan input di form kunci (field wajib, format dasar, batas panjang dan numerik)
• Perilaku client API dengan layer HTTP yang dimock (timeout, retry, penanganan “tidak ada internet”)
• Satu tes yang memastikan Anda menampilkan pesan ramah saat server mengembalikan error validasi

Contoh konkret: layar “Create Project” yang dibangun dengan Koder.ai mungkin menerima nama proyek dan region. Unit-test bahwa nama kosong diblokir, whitespace dipangkas, dan nilai region yang belum pernah terlihat dari API tidak merusak dropdown.

Golden UI tests bisa membantu, tapi gunakan jarang. Gunakan hanya untuk beberapa layar stabil di mana regresi tata letak benar-benar menyakitkan, seperti layar login, dashboard utama, atau alur checkout/create kritis.

Tes integrasi bernilai tinggi di antara React, Go, dan Postgres

Saat Anda membangun cepat dengan alat chat, bug paling menyakitkan muncul antar lapis: halaman React memanggil API, handler Go menulis ke Postgres, lalu UI menganggap bentuk respons yang berubah. Tes integrasi adalah cara tercepat menangkap break lintas-lapis itu tanpa mencoba menguji semuanya.

Aturan yang baik: untuk setiap resource inti (users, projects, orders, dll.), uji satu path nyata yang didukung Postgres end-to-end melalui Go API. Bukan setiap edge case. Hanya satu happy path yang membuktikan wiring bekerja.

Set integrasi minimal yang menangkap sebagian besar regresi

Mulailah dengan beberapa pengecekan sinyal tinggi:

• Path API + DB per resource inti: create atau update via HTTP, lalu verifikasi ada (dengan membacanya kembali via API atau memeriksa field yang tersimpan)
• Stabilitas kontrak: kunci bentuk request dan response untuk endpoint yang paling diandalkan klien
• Integrasi auth: verifikasi parsing token, cek role, dan perbedaan antara 401 dan 403
• React -> API submit utama: satu tes untuk jalur submit form utama (sukses plus satu error umum)
• Flutter -> API read/write utama: satu list/detail read plus satu aksi tulis utama menggunakan endpoint produksi

Jaga mereka stabil: satu skenario, data nyata, permukaan kecil

Gunakan instance Postgres nyata untuk tes ini (sering database disposable). Seed hanya yang Anda butuhkan, bersihkan setelah setiap tes, dan fokuskan assertion pada hal yang pengguna perhatikan: data tersimpan benar, permission ditegakkan, dan klien bisa parse respons.

Contoh: fitur “Create Project”. Tes integrasi Go memanggil POST /projects, memeriksa respons 201, lalu mengambil project dan mengonfirmasi nama dan owner ID. Tes integrasi React mengirim form create dan mengonfirmasi state sukses menampilkan nama baru. Tes Flutter membuka daftar projects, membuat project, dan mengonfirmasi muncul setelah refresh.

Jika Anda menghasilkan aplikasi di Koder.ai, tes ini juga melindungi saat UI atau handler yang digenerate berubah bentuk payload atau format error.

Tes e2e minimal yang tetap stabil

E2E adalah jaring pengaman “apakah aplikasi bekerja end to end?” Mereka paling berharga saat tetap kecil dan membosankan: smoke test yang membuktikan wiring antara React, Go API, Postgres, dan klien Flutter masih utuh setelah perubahan.

Pilih hanya beberapa perjalanan yang mewakili uang nyata atau rasa sakit nyata jika rusak: sign in/out, buat record, edit dan simpan, cari/filter dan buka hasil, dan checkout/payment (jika ada).

Jalankan ini pada satu browser dan satu profil perangkat dulu (mis. Chrome untuk web dan satu ukuran ponsel tipikal untuk mobile). Perluas ke browser atau perangkat lain hanya saat pelanggan melaporkan masalah nyata di sana.

Stabilitas adalah fitur. Buat tes deterministik sehingga gagal hanya saat benar-benar rusak:

• Gunakan akun uji tetap dan data seed
• Bekukan waktu (atau atur jam aplikasi) agar logika tanggal tetap terduga
• Tunggu sinyal jelas (elemen spesifik, perubahan route, atau respons API), bukan sleep acak
• Reset state antara run (pembersihan DB atau tenant baru)
• Perbaiki tes flaky minggu ini atau hapus mereka

Gunakan e2e untuk memvalidasi jalur utama, bukan setiap edge case. Edge case milik unit dan integrasi test yang lebih murah dan kurang rapuh.

Apa yang bisa dilewatkan (atau ditunda) tanpa penyesalan

Cara tercepat membuang-buang waktu adalah menulis tes yang terlihat menyeluruh tapi jarang menangkap bug nyata. Set kecil dan fokus menang lebih baik daripada jaring luas yang tidak dipercaya siapa pun.

Snapshot tests adalah jebakan umum di React dan Flutter. Snapshot besar berubah karena alasan harmless (teks berubah, layout bergeser, refactor kecil), jadi tim either menerima update yang berisik atau berhenti melihat kegagalan. Simpan snapshot hanya untuk permukaan kecil yang stabil, seperti output formatter kecil, bukan seluruh layar.

Lompatan lain yang mudah dilewatkan: menguji library pihak ketiga. Anda tidak perlu membuktikan React Router, date picker, atau HTTP client bekerja. Uji titik integrasi Anda saja: tempat Anda mengonfigurasi, memetakan data ke, atau menangani error-nya.

Tes styling jarang sepadan. Pilih pengecekan perilaku (tombol disabled saat form invalid, pesan error ditampilkan pada 401) daripada assertion pixel-level. Buat pengecualian jika styling memengaruhi perilaku atau kepatuhan: persyaratan kontras, outline fokus untuk pengguna keyboard, atau layout responsif kritis yang mengubah apa yang bisa dilakukan pengguna.

Hindari menggandakan pengecekan yang sama di setiap lapis. Jika Anda sudah asert di integrasi Go bahwa request unauthorized mengembalikan 401, Anda mungkin tak perlu assertion identik di unit test dan e2e.

Tes performa layak dilakukan, tapi nanti. Tunggu sampai alur aplikasi stabil (mis. setelah fitur yang digenerate Koder.ai berhenti berubah setiap hari), lalu tetapkan satu atau dua target terukur dan pantau konsisten.

Contoh: satu fitur, set tes minimum untuk semua lapis

Misal Anda mengirim fitur sederhana: user signed-in mengedit profil dan mengganti email. Ini good canary karena menyentuh state UI, aturan API, dan caching klien.

Berikut set tes minimum yang biasanya menangkap sebagian besar regresi tanpa berubah jadi suite penuh.

Tes 80/20 untuk fitur ini

• React (unit): perilaku form. Jika email tidak valid, submit tetap disabled dan error inline muncul. Jika email valid, submit aktif. Tambahkan satu tes bahwa banner error muncul saat API mengembalikan error yang dikenali (mis. “email already in use”).
• Go API (unit): aturan bisnis. Validasi format email dan blokir nilai kosong. Jika aturan Anda “email harus unik”, uji cek unik dan kode/error pesan yang tepat yang diandalkan klien. Juga uji bahwa field audit ter-update (mis. updated_at berubah) saat email diganti.
• Flutter (unit/widget): state layar dan messaging. Saat sukses, layar menampilkan email baru dan menghapus error lama. Saat gagal, user melihat pesan jelas dan tombol submit kembali ke state yang bisa digunakan.
• Integrasi (Go + Postgres): update dan unik. Buat dua user, coba set email user A ke email user B, asert kegagalan yang tepat, dan pastikan DB tidak ter-update sebagian.
• E2E (satu happy path): ganti email end to end. Login, buka profil, ganti email, simpan, refresh, dan konfirmasi persist.

Apa yang tercakup (dan mengapa cukup)

Set ini menargetkan titik-titik break umum: validasi UI dan state disabled di React, drift aturan di Go, dan UI yang kadaluarsa atau membingungkan di Flutter. Jika Anda membangun dengan platform seperti Koder.ai, di mana kode bisa berubah cepat lintas lapis, tes ini memberi sinyal cepat dengan pemeliharaan minimal.

Langkah demi langkah: bangun rencana tes prioritas dalam satu jam

Atur timer 60 menit dan fokus pada risiko, bukan kesempurnaan. Kode yang dihasilkan chat bisa terlihat benar tetapi masih melewatkan aturan kecil, edge case, atau wiring antar lapis. Tujuan Anda adalah set tes singkat yang gagal lantang saat perilaku berubah.

0–15 menit: pilih alur yang paling menghasilkan

Tuliskan 5 aksi pengguna yang harus bekerja setiap saat. Buat konkret: “sign in”, “create an order”, “pay”, “lihat riwayat order”, “reset password”. Jika Anda membangun di Koder.ai, pilih apa yang bisa Anda demo end to end hari ini, bukan yang Anda harap tambahkan nanti.

15–35 menit: kunci aturan dengan tes kecil

Untuk setiap flow, temukan satu aturan yang akan menyebabkan kerusakan nyata jika salah. Tambahkan satu unit test cepat per lapis tempat aturan itu berada:

• React: validasi, format, state kondisional (loading, empty, error)
• Go API: aturan bisnis, cek permission, edge input
• Flutter: mapping klien, transisi state, retry dan offline

Contoh: “Checkout tidak boleh mengizinkan quantity negatif.” Uji sekali di API, dan sekali di UI/klien jika klien juga menegakkannya.

35–50 menit: tambahkan satu cek integrasi nyata per flow

Tambahkan satu integration test per flow yang memanggil API nyata dan melakukan tulis DB nyata di Postgres. Jaga narrow: create, update, fetch, dan verifikasi hasil tersimpan. Ini menangkap wiring yang salah seperti nama field yang keliru, transaksi hilang, atau migrasi rusak.

50–60 menit: pilih e2e minimal dan atur urutan CI

Pilih 3–6 e2e flow total. Utamakan jalur lintas-lapis paling banyak (login -> create -> view). Tentukan data uji stabil (user seed, ID yang diketahui, jam beku) supaya tes tidak tergantung random.

Jalankan tes dalam urutan ini di CI: unit test setiap push, integration test setiap push atau di main, dan e2e hanya di main atau nightly bila memungkinkan.

Kesalahan umum, checklist cepat, dan langkah berikutnya

Cara tercepat membuang waktu adalah menguji hal yang salah pada level yang salah. Sebagian besar kegagalan bisa diprediksi: kontrak yang tidak jelas, mock yang tidak realistis, dan suite yang tak dipercaya siapa pun.

Salah satu kesalahan umum adalah mulai menulis tes sebelum menyepakati kontrak API. Jika Go API mengubah kode error, nama field, atau aturan pagination, klien React dan Flutter akan gagal dengan cara yang tampak acak. Tulis kontrak dulu (request, response, status code, bentuk error), lalu kunci dengan beberapa integration test.

Perangkap lain adalah overusing mocks. Mock yang tidak berperilaku seperti Postgres, middleware auth, atau respons jaringan nyata memberi rasa aman palsu. Gunakan unit test untuk logika murni, tapi pilih integration test tipis untuk apa pun yang melintasi batas proses.

Kesalahan ketiga adalah mengandalkan end-to-end tests untuk segala hal. E2E lambat dan rapuh, jadi gunakan hanya untuk melindungi jalur pengguna bernilai tinggi. Masukkan sebagian besar coverage ke unit dan integration test di mana kegagalan lebih mudah didiagnosis.

Terakhir, jangan abaikan flaky tests. Jika tes gagal kadang-kadang, tim berhenti mendengarkan. Perlakukan tes flaky sebagai bug di pipeline delivery dan perbaiki cepat.

Checklist cepat sebelum menambah tes:

• Daftar alur pengguna teratas dan mode kegagalan teratas (auth, payments, simpan data, search, offline)
• Asert kontrak API dan kode error dengan beberapa integration test
• Simpan 3–6 e2e flow stabil yang sesuai tujuan pengguna nyata
• Hapus atau tulis ulang tes flaky dalam sehari, bukan “nanti”
• Tinjau kegagalan berdasarkan kategori (React, Go API, DB, Flutter) agar pola terlihat

Langkah berikutnya: implementasikan rencana, pantau regresi per lapis, dan jaga suite tetap kecil dengan sengaja. Jika Anda membangun dengan Koder.ai, ada baiknya menambahkan tes segera setelah Anda mengonfirmasi kontrak API yang digenerate dan sebelum memperluas fitur.

Jika Anda bekerja pada aplikasi yang digenerate melalui Koder.ai dan ingin satu tempat untuk iterasi lintas web, backend, dan mobile, platform Koder.ai dirancang mengelola alur itu. Apa pun alat yang Anda gunakan, pendekatan pengujian tetap sama: kunci kontrak, cover jalur utama, dan jaga suite cukup membosankan sehingga Anda benar-benar menjalankannya.