Menulis kasus uji pertama Anda

Sampai sekarang Anda mengirim request dan melihat apa yang kembali. Pengujian dimulai saat Anda memutuskan, sebelum mengirim, apa yang seharusnya kembali, lalu membandingkannya. Keputusan yang dituliskan itu adalah kasus uji. Pelajaran ini membahas cara menulisnya, dan cara memilih mana yang perlu ditulis, karena Anda tidak bisa mengirim setiap request yang mungkin.

Isi sebuah kasus uji

Tim memakai template yang berbeda-beda, tetapi hampir semuanya punya bagian yang sama:

Hasil yang diharapkan adalah bagian yang sering ditulis dengan buruk. "Mengembalikan error" bukan hasil yang diharapkan, karena hampir apa pun lolos. Tulis dengan spesifik kode statusnya, header yang penting (biasanya Content-Type, kadang header cache atau location), dan body-nya: field apa yang harus ada, dengan tipe dan nilai apa. Jika Anda tidak bisa menyebut jawaban yang benar, Anda menemukan pertanyaan untuk developer atau product owner, dan itu layak ditanyakan sebelum Anda menguji apa pun.

Dari mana hasil yang diharapkan berasal? Dari dokumentasi, tiket yang mendeskripsikan fitur itu, perilaku endpoint serupa di API yang sama, dan kadang akal sehat biasa (harga seharusnya tidak negatif). Saat sumber-sumber ini tidak sejalan, catat mana yang Anda ikuti.

Tes positif dan negatif

Tes positif mengirim request yang valid dan memeriksa bahwa request itu berhasil: produk 1 ada, jadi GET /api/Products/1 mengembalikannya. Tes negatif mengirim sesuatu yang seharusnya ditolak API dan memeriksa bahwa penolakannya benar: status yang tepat, pesan yang berguna, dan tanpa efek samping.

Pemula kebanyakan menulis tes positif, karena mereka mengikuti deskripsi fitur. Developer biasanya sudah mencoba jalur positif sendiri sebelum menyerahkan pekerjaannya. Tes negatiflah tempat Anda menemukan masalah. Sebagai patokan kasar, siapkan diri untuk menulis lebih banyak tes negatif daripada positif untuk endpoint mana pun yang menerima input.

Kelas ekuivalen

Endpoint daftar GET /api/Products menerima parameter limit. Referensi API menyebut bahwa itu ukuran halaman, dari 1 sampai 100. Ada tak terhingga nilai yang bisa Anda kirim. Partisi kelas ekuivalen berarti mengelompokkan input yang seharusnya diperlakukan sama oleh server, lalu menguji satu nilai dari setiap kelompok alih-alih semuanya:

Perhatikan entri "ditolak, atau disesuaikan". Dokumentasi tidak menyebut apa yang terjadi di luar rentang, jadi ada dua perilaku yang masuk akal. Keduanya bisa dibenarkan. Yang Anda uji adalah bahwa API melakukan salah satunya, secara konsisten, dan tidak crash atau mengembalikan sesuatu yang tidak masuk akal.

Nilai batas

Bug berkumpul di tepi rentang, karena di situlah developer menulis < padahal maksudnya <=. Analisis nilai batas berarti menguji batasnya dan satu langkah di kedua sisinya. Untuk rentang 1 sampai 100, itu menghasilkan 0, 1, 2, 99, 100, dan 101. Berikut yang benar-benar dilakukan API ini terhadap nilai-nilai itu dan kelas lainnya. Header X-Per-Page melaporkan ukuran halaman yang dipakai server.

Membaca hasilnya: nilai di bawah 1 dinaikkan ke 1, nilai di atas 100 diturunkan ke 100, dan apa pun yang bukan bilangan bulat diabaikan seolah limit tidak ada. Semua ini tidak tertulis, tetapi konsisten, jadi mungkin disengaja. Tetap saja, dua hal layak dicatat dalam laporan pengujian Anda. limit=0 yang mengembalikan satu item itu mengejutkan; klien yang meminta nol item (misalnya untuk membaca total dengan murah) mendapat produk yang tidak diinginkannya. Dan limit=abc yang diabaikan diam-diam berarti salah ketik di klien tidak ketahuan, padahal 400 akan menangkapnya.

Ada juga pelajaran tentang data uji di sini. API ini hanya punya 20 produk, jadi limit=100 dan limit=101 mengembalikan body yang sama. Dari body-nya Anda tidak bisa tahu bahwa 101 disesuaikan. Header-lah yang menunjukkannya. Saat batasnya lebih besar dari data Anda, cari sinyal lain seperti ini atau buat cukup banyak data untuk mencapai batas itu.

Batas juga bersembunyi di ID

Referensi mencantumkan id di /api/Products/{id} sebagai int32, bilangan bulat 32-bit yang nilai terbesarnya 2.147.483.647. Itu batas yang layak diuji:

Dua hal menonjol. Semua yang bukan int32 valid mendapat 404 tanpa body sama sekali, sementara ID yang valid tetapi tidak ada mendapat error JSON. Dan 01 diterima sebagai 1. Yang kedua tidak berbahaya di sini, tetapi pada API yang menyimpan response di cache per URL, /1 dan /01 akan disimpan terpisah. Tidak satu pun hasil itu jelas salah. Keduanya layak diketahui.

Sekumpulan kasus uji untuk satu endpoint

Jika disatukan, kumpulan kasus uji awal yang masuk akal untuk GET /api/Products/{id} terlihat seperti ini. Ini bukan semua yang bisa Anda uji, tetapi mencakup setiap kelas sekali dan setiap batas.

PROD-GET-06 dan 07 gagal terhadap API saat ini, karena body-nya kosong. PROD-GET-08 juga gagal: HEAD /api/Products/1 mengembalikan 405 Method Not Allowed, sementara resource yang lebih baru seperti /api/Books/{id}masuk untuk melihat mendukung HEAD. Apakah dukungan HEAD diharapkan di sini adalah pertanyaan untuk pemilik API. Tidak masalah. Kasus uji mencatat apa yang seharusnya terjadi; kasus uji yang gagal adalah cara Anda mengetahui bahwa hal itu tidak terjadi. PROD-GET-02 punya kelemahan: jika seseorang menghapus produk 20 atau menambah produk 21, kasus itu tidak lagi berarti seperti yang tertulis. Pelajaran berikutnya menunjukkan cara membuat data uji sendiri agar tes tidak bergantung pada data yang dikendalikan orang lain.

Menulis laporan bug

Saat kasus uji gagal, Anda menuliskannya. Laporan bug yang baik memungkinkan developer mereproduksi masalah dalam waktu kurang dari satu menit tanpa bertanya apa pun kepada Anda. Dengan memakai 404 kosong di atas sebagai contoh, bandingkan dulu kedua response-nya:

HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8

{"status":404,"error":"Not Found","message":"Product with ID 9999 does not exist."}

HTTP/1.1 404 Not Found
Content-Length: 0

Sebuah laporan bisa berbunyi (di sini dalam bahasa Inggris, seperti yang ditulis banyak tim):

Title: GET /api/Products/{id} returns an empty 404 for non-numeric
       and out-of-range IDs, instead of the JSON error body

Environment: https://api.testingapis.com, 30 Sep 2026

Steps:
  curl -i https://api.testingapis.com/api/Products/9999
  curl -i https://api.testingapis.com/api/Products/abc
  curl -i https://api.testingapis.com/api/Products/2147483648

Expected:
  All three return 404 with Content-Type: application/json and a body
  like {"status":404,"error":"Not Found","message":"..."}, as documented
  under "Responses and errors" in the API reference.

Actual:
  9999        404, JSON body with a message
  abc         404, Content-Length: 0, no Content-Type, no body
  2147483648  404, empty body (one above the int32 maximum; 2147483647
              returns the JSON error)

Impact:
  Clients that parse every error body as JSON fail on the empty
  responses. The empty 404 also looks like "this URL does not exist"
  rather than "this product does not exist".

Notes:
  Probably the route only matches int32 values, so other input never
  reaches the controller. Could be intended; if so, the docs should say
  which errors have no body.

Yang membuat laporan ini berguna:

• Judulnya menyebut apa yang salah dan di mana, jadi tetap jelas di antara lima puluh tiket.
• Langkah-langkahnya berupa perintah yang bisa ditempel. Bukan "panggil endpoint produk dengan ID yang buruk".
• Perilaku yang diharapkan merujuk ke sebuah sumber (dokumentasi), jadi bukan sekadar preferensi Anda.
• Laporan ini menunjukkan polanya, bukan satu contoh saja. Tiga request, dengan satu yang berhasil sebagai pembanding, lebih berbicara daripada satu request yang gagal.
• Laporan ini menyebut dampaknya pada klien sungguhan. Developer menentukan prioritas berdasarkan dampak, dan "tidak konsisten" saja jarang diperbaiki.
• Laporan ini mengakui ketidakpastian. Perilaku itu mungkin disengaja, dan laporan menyebut apa yang akan menyelesaikannya ke arah mana pun (memperbaiki kode, atau memperbaiki dokumentasi).