Keuntungan:
- Kemampuan untuk mencegah kecerdasan buatan menerima perilaku yang salah sebagai 'benar' dengan menghitung nilai yang diharapkan dalam pengujian unit secara independen dari aturan penerimaan
- Kemampuan untuk mencetak pengujian yang cepat, independen, dan berulang dengan menerapkan prinsip AAA dan FIRST serta meniru ketergantungan eksternal
- Kemampuan untuk menguji pengujian dengan mutasi (pemecahan kode) dan mengenali kode yang sulit diuji sebagai bau desain
Lapisan terbesar dan tercepat dari piramida pengujian adalah pengujian unit — pengujian yang memverifikasi suatu fungsi atau potongan kecil kode secara terpisah dari yang lainnya. Ribuan pengujian unit dijalankan dalam hitungan detik dan menemukan bug saat kode masih ada di layar pengembang. Kecerdasan buatan (AI) mungkin paling mahir dalam menghasilkan pengujian unit: Anda memberinya fungsi, AI menghasilkan lusinan pengujian. Namun kemudahan ini menimbulkan jebakan terbesar: AI dengan mudah menghasilkan pengujian yang “bersinar hijau tetapi tidak memverifikasi apa pun” atau menerima perilaku kode saat ini (yang mungkin salah) sebagai “benar”. Dalam unit ini Anda akan mempelajari cara menulis pengujian unit yang benar-benar protektif dengan AI dan hubungan antara kode yang dapat diuji dan AI.
Kualitas tes unit yang baik: PERTAMA
Pengujian unit yang baik mengikuti prinsip PERTAMA: Cepat, Independen (pengujian tidak boleh bergantung satu sama lain), Dapat Diulang (dapat diulang — hasil yang sama di lingkungan apa pun), Validasi mandiri (lulus/gagal), Tepat Waktu (tepat waktu). Ingatkan diri Anda tentang prinsip-prinsip ini saat meminta AI menghasilkan pengujian; secara khusus meminta agar pengujian tidak bergantung pada dunia luar (database aktual, jaringan, jam) agar "independen" dan "dapat diulang".
Pola AAA dan penegasan ekspresif
Pengujian unit yang solid mengikuti struktur AAA: Arrange (persiapkan — siapkan input dan dependensi), Act (eksekusi — panggil fungsi yang diuji), Assert (validasi — bandingkan hasilnya dengan nilai yang diharapkan). Yang kritis adalah menegaskan. Kesalahan paling umum yang dilakukan AI adalah memperoleh pernyataan dari keluaran kode yang diuji — logika “apa pun yang dikembalikan oleh kode adalah benar”. Hal ini membuat tes menjadi tidak ada artinya. Cara yang benar adalah dengan menentukan nilai yang diharapkan secara mandiri (dari kriteria penerimaan, hitung secara manual).
Perhatian: Jika Anda memberi tahu AI "tulis tes untuk fungsi ini", AI dapat menjalankan fungsi tersebut dan menulis outputnya seperti "yang diharapkan". Tes ini lolos meskipun fungsinya salah. Sebaliknya, ucapkan "Anda menghitung hasil yang diharapkan berdasarkan aturan ini, jangan merujuk pada keluaran fungsi saat ini."
Mocks, stub dan dependensi
Pengujian unit memerlukan isolasi. Jika fungsi Anda bergantung pada database atau API, fungsi tersebut akan diganti dengan objek tiruan (mock/stub — pengganti dependensi sebenarnya yang terkontrol dan tiruan) dalam pengujian. Hal ini menjadikan pengujian ini cepat, independen, dan dapat direproduksi. AI dapat menghasilkan instalasi tiruan; Namun hati-hati terhadap ejekan yang berlebihan: jika Anda meniru semuanya, pengujian hanya akan memverifikasi "apa yang dikembalikan tiruannya", bukan logika sebenarnya. Keseimbangan: meniru dunia luar, menjalankan logika nyata yang diuji.
Kemampuan untuk diuji dan AI
Ada masukan yang menarik: kode yang sulit diuji sering kali merupakan kode yang dirancang dengan buruk. Jika AI kesulitan menulis tes ke suatu fungsi (terlalu banyak ketergantungan, status global tersembunyi, efek samping), itu adalah bau desain. Menanyakan kepada AI “bagaimana Anda memfaktorkan ulang kode ini agar dapat diuji” akan menghasilkan pengujian dan kode yang lebih baik.
Tes berparameter dan keragaman data
Menulis tes terpisah setiap kali untuk memverifikasi aturan yang sama dengan masukan yang berbeda adalah hal yang membosankan dan sulit untuk dipertahankan. Pengujian berparameter — struktur yang berulang kali menjalankan logika pengujian yang sama pada daftar masukan dan hasil yang diharapkan — menghilangkan pengulangan ini: satu badan pengujian diberi lusinan pasangan masukan. AI sangat efisien dalam menghasilkan tabel hasil yang diharapkan dari masukan ini ketika Anda memberikan aturan penerimaannya; Secara khusus, ia secara sistematis membuat tabulasi nilai batas dan kelas kesetaraan.
Namun ada jebakan di sini juga: AI cenderung memperoleh hasil yang diharapkan dalam tabel yang dihasilkan dari kode yang diuji. Kesalahan ini bahkan lebih berbahaya dalam pengujian berparameter, karena satu logika yang salah akan membatalkan lusinan baris. Oleh karena itu, kolom hasil yang diharapkan selalu dihitung secara independen sesuai dengan aturan penerimaan dan validasi secara manual setidaknya beberapa baris. Minta juga kolom deskripsi "mewakili apa setiap baris"; jadi ketika sebuah baris terputus, Anda langsung melihat status mana yang rusak.
Tip: Secara sengaja menambahkan “baris jebakan” ke tabel pengujian berparameter — yaitu, dengan sengaja salah mengetikkan hasilnya. Jika garis tersebut tidak berubah menjadi merah saat Anda menjalankan pengujian, pengujian Anda sebenarnya tidak memverifikasi situasi tersebut. Ini adalah pemeriksaan mock-pass cepat.
Perintah lemah / Perintah kuat
Lemah: "Tulis pengujian unit untuk fungsi ini."
Kuat: Tulis pengujian unit [bahasa/kerangka] untuk fungsi "taxCalculate(amount, rate). Aturan penerimaan: hasil = jumlah * tarif, dibulatkan menjadi 2 desimal; jumlah atau tarif negatif menimbulkan kesalahan; mengembalikan 0 jika tarif adalah 0. Gunakan struktur AAA. Hitung nilai yang diharapkan secara manual sesuai dengan aturan INI; jangan referensikan keluaran fungsi saat ini. Tutupi kasus terikat dan negatif (0, negatif, sangat besar, bulatkan ke desimal). Biarkan nama setiap pengujian menjelaskan aturannya memverifikasi. Ketergantungan eksternal "Tidak."
Perintah yang kuat; Ini memberikan aturan penerimaan, ekspektasi nilai independen yang diharapkan, struktur dan kasus tepi. Dengan demikian, ujian menjadi penjaga aturan, bukan cerminan kode.
Tabel kualitas pengujian unit
gejala
Ujian yang buruk (kepercayaan palsu)
tes yang bagus
menegaskan
Tidak ada atau "bukan nol"
Nilai konkrit yang diharapkan
Sumber nilai yang diharapkan
Keluaran dari fungsi tersebut
Aturan penerimaan / perhitungan manual
kecanduan
DB/jaringan/jam aktual
Terisolasi dengan tiruan/rintisan
kasus tepi
Hanya jalan bahagia
batas, negatif, kesalahan
Saat Anda memecahkan kodenya
tetap hijau
berubah menjadi merah
Nama
tes1, metode tes
menjelaskan aturan yang ditegaskannya
Empat templat yang dapat disalin
1) Pengujian unit berdasarkan aturan:
Peran Anda: insinyur pengujian perangkat lunak senior. Tulis pengujian unit pada fungsi berikut dengan [bahasa/kerangka]: [tanda tangan]. Aturan penerimaan: [aturan]. - Gunakan struktur AAA. - Hitung nilai yang diharapkan secara manual sesuai dengan aturan INI; JANGAN mereferensikan keluaran fungsi saat ini. - Tutupi jalur batas, negatif, kesalahan, dan bahagia dengan tes terpisah. - Biarkan setiap nama pengujian menjelaskan aturan yang diverifikasinya. - Mengejek ketergantungan eksternal; Jadikan logika sebenarnya berfungsi.
2) Kontrol resistensi mutasi:
Lihat tes unit ini. Sebutkan 5 perubahan kecil yang dapat saya lakukan pada kode yang sedang diuji (a - alih-alih a +, a >= alih-alih a >, pergeseran batas) dan beri tahu saya untuk masing-masing pengujian manakah yang akan berubah menjadi merah? Jika tidak ada yang dikembalikan, pengujian tidak mencukupi. Kode + pengujian: [tempel]
3) Tinjauan kemampuan pengujian:
Mengapa sulit menulis unit test untuk fungsi ini? Kecanduan tersembunyi, status global, efek samping, apakah ada banyak tanggung jawab? Sarankan pemfaktoran ulang minimal agar dapat diuji; jangan mengubah perilaku. Kode: [tempel]
4) Penyelesaian skenario tidak lengkap:
Fungsi berikut dan tes yang tersedia diberikan. Buat daftar perilaku/edgecase mana yang BELUM PERNAH diuji (kesenjangan cakupan) dan tambahkan pengujian untuk masing-masingnya. Fungsi+tes: [tempel]
tiga kasus mini
Kasus 1 — Uji pencerminan kode. Pengembang meminta AI menulis tes untuk fungsi pembulatan; 10 tes berwarna hijau. Faktanya, fungsi tersebut dibulatkan ke arah yang salah, tetapi AI telah mengambil nilai yang diharapkan dari keluaran fungsi tersebut, sehingga pengujian menganggap kesalahan tersebut "benar". Ketika nilai yang diharapkan dihitung secara manual dengan templat "berdasarkan aturan", 4 pengujian berubah menjadi merah dan kesalahan sebenarnya terungkap.
Kasus 2 — Nilai pengendalian mutasi. Satu tim mengandalkan 45 unit tes. Mencoba 20 perubahan kecil pada kode dengan "pemeriksaan ketahanan mutasi"; tes hanya menangkap 11 di antaranya. 9 gangguan sisanya berlalu secara diam-diam. Tim memperkuat tes yang lemah; Kesalahan perhitungan sebenarnya terdeteksi oleh pengujian yang ditingkatkan ini pada rilis berikutnya.
Kasus 3 - Ketidakmampuan untuk diuji adalah bau desain. AI tidak dapat menulis tes untuk fungsi pemesanan, AI selalu membutuhkan database yang sebenarnya. Templat "tinjauan testabilitas" menunjukkan bahwa fungsi akses basis data tertanam. Ketika injeksi ketergantungan dihilangkan, pengujian dapat ditulis dan kode menjadi lebih bersih.
Kesalahan umum
- Mendapatkan nilai yang diharapkan dari kode. AI menerima keluaran fungsi sebagai "benar"; tes yang mengkonfirmasi kode yang salah.
- Uji tanpa pernyataan atau dengan pernyataan sepele. "Dia tidak membuat kesalahan, dia melewati" logika; Itu tidak mengkonfirmasi apa pun.
- Tiruan yang ekstrem. Mengejek segalanya dan hanya menguji apa yang dikembalikan oleh tiruan itu; logika nyata tidak diuji.
- Hanya jalan bahagia. Melewati batas, status negatif dan kesalahan.
- Tidak menguji dengan memecahkan kode. Mempercayai warna hijau tanpa memeriksa mutasi.
- Mengabaikan ketidakpastian. Tidak mengenali dan memperbaiki desain yang buruk alih-alih melakukan pengujian yang sulit.
Singkatnya
Tes unit adalah lapisan piramida pengujian tercepat dan terbesar; Ini menangkap kesalahan pada saat yang paling murah. AI sangat mampu menghasilkan pengujian unit, namun kelemahan terbesarnya adalah menulis pengujian yang menganggap perilaku yang salah sebagai "benar" dengan memperoleh nilai yang diharapkan dari kode itu sendiri. Solusi: berikan aturan penerimaan, hitung nilai yang diharapkan secara manual, terapkan prinsip AAA dan FIRST, tiru dunia luar dan jalankan logika sebenarnya, dan uji setiap pengujian dengan mutasi (memecah kode). Kode yang sulit untuk diuji adalah tanda desain yang perlu diperbaiki.
Tugas aplikasi
Pilih fungsi yang berisi aturan bisnis dari proyek Anda sendiri. Menulis aturan penerimaan dan melakukan tes tulis AI dengan templat “pengujian unit berbasis aturan”; Mintalah nilai yang diharapkan dihitung secara manual. Kemudian terapkan “pemeriksaan ketahanan mutasi”: buat setidaknya 5 jeda kecil pada kode dan ukur berapa banyak pengujian yang berubah menjadi merah. Tambahkan tes baru untuk korupsi yang tidak tertangkap. Laporkan berapa banyak gangguan yang terdeteksi (seperti skor mutasi).
daftar periksa
- [] Saya memberikan aturan penerimaan dan menghitung nilai yang diharapkan secara manual.
- [ ] Saya memastikan bahwa pengujian tidak mendapatkan nilai yang diharapkan dari kode.
- [ ] Saya telah melakukan pengujian independen mengikuti pedoman AAA dan PERTAMA.
- [] Saya meniru dependensi eksternal dan menjalankan logika sebenarnya.
- [ ] Saya membahas kasus batas, negatif, dan kesalahan.
- [ ] Dengan memecahkan kode (mutasi) saya membuktikan bahwa tes tersebut memang melindungi.