Menyusun Testing untuk Django REST
Hehehe… Saya sangat menyukai seri komik dilbert di atas. Jika anda berkecimpung di dunia programming, paling tidak anda akan menemui salah satu chapter dari seri komik tersebut. Oke, kita mulai saja sesi kali ini.
Bertemu dengan saya kembali, Yudistira. Kali ini saya mau berbagi cerita bagaimana saya menyusun testing, terutama unit testing, saat menggunakan Django REST. Apakah terdapat perbedaan dengan unit test Django biasa? Adakah library generic khusus yang sudah tersedia sehingga langsung bisa digunakan? Mari kita bahas satu per satu.
Django REST framework
Django REST merupakan framework yang dapat digunakan untuk membangun suatu arsitektur perangkat lunak yang menggunakan atau menerapkan REST. Django REST ini merupakan ekstensi dari Django biasa sehingga bagi anda yang sudah pernah menggunakan Django akan mudah untuk menggunakannya.
Penggunaan Django REST di ppl-teman-bisnis
Kelompok kami menggunakan Django REST untuk membangun backend berupa RESTful api. API ini yang nantinya akan dipanggil oleh sisi frontend maupun dari aplikasi teman bisnis untuk mencatat dan menampilkan event-event yang dilakukan oleh pengguna aplikasi.
Pada sprint kali ini, saya mengambil task membuat api untuk mendaftarkan atau mencatat user event. User event merupakan entitas dalam database kami dan sudah dibuatkan oleh teman saya (Terima kasih teman saya !!). Jadi, tugas cukup membuat endpoint untuk pengguna apabila ingin mendaftarkan user event dan juga mengembalikan daftar user event.
TDD !
Penggunaan Django REST tidak lupa disertakan dengan penerapan TDD dalam pengembangan software. Saya akan membahas TDD secara singkat sebelum masuk ke tahap implementasinya.
Test-Driven Development
Test-Driven Development atau biasa disingkat TDD adalah proses pengembangan perangkat lunak yang melakukan pengulangan suatu siklus pengembangan tertentu. Siklus tersebut menjadikan “Test” sebagai hal yang diperhatikan dalam setiap tahap. Secara sederhana, suatu siklus pengembangan yang menerapkan TDD adalah sebagai berikut:
- Menetapkan fitur yang ingin dikerjakan (cukup membuat stub).
- Membuat test sesuai dengan fitur.
- Menjalankan test sehingga test yang baru saja dibuat gagal. [RED]
- Menuliskan kode yang membuat test berhasil.
- Menjalankan test kembali dan berhasil. [GREEN]
- (Optional) Melakukan refactoring pada kode. [REFACTOR]
- Jika melakukan refactoring, pastikan test tetap berhasil. [GREEN]
- Ulangi dari langkah 1.
Mata kuliah PPL pun sudah menyesuaikan pengerjaan proyek dengan TDD, yaitu dengan mewajibkan memberi label pada setiap commit dengan [RED], [GREEN] dan [REFACTOR]. Terus saja mengulangi langkah-langkah di atas sampai semua fitur yang dikerjakan selesai … ya, melelahkan tapi mari kita coba terlebih dahulu.
Langkah-langkah
Seperti biasa, tahap pertama yang harus dilalui adalah merancang dan membuat test. Sebelum membuat test, saya perlu mengetahui apa saja yang dibutuhkan.
Cek Kebutuhan
https://www.django-rest-framework.org/api-guide/generic-views/
Pertama, saya ingin membuat controller/API view yang akan membuat objek user event pada database. Django REST sudah menyediakan generic class yang dapat digunakan untuk membuat dan melihat model, yaitu List Create API View (setiap kata harusnya disambung). Berarti saya perlu membuat stub dari class view yang akan saya gunakan supaya. OK!.
Kedua, melihat pada skenario menembak api. Skenarionya adalah di dalam aplikasi tebi (teman bisnis) akan menembak suatu url dengan membawa parameter data yang dibutuhkan. Ada dua hal yang perlu dipersiapkan di sini, url dan parameter data.
Untuk url, saya perlu menyambung suatu url dengan controller yang bersangkutan. Hal ini bisa diatur dengan mengubah file urls.py.
Sehingga untuk mengakses APIView yang ingin dibuat, cukup menembak ke url api/user-events/ .
Selanjutnya adalah data. Saya perlu mempersiapkan data dalam penyusunan test. Data tersebut harus berupa dummy yang hanya digunakan pada test saja (mock data). Hal ini dijelaskan dalam F.I.R.S.T Principles of Unit Testing, yaitu huruf I yang berarti Isolated atau Independent. Data yang saya siapkan adalah data User dummy dan data Event dummy. Berikut implementasi kodenya.
Django REST juga sudah menyediakan class APITestCase yang dapat digunakan untuk membuat test case yang relevan pada API.
Membuat Test
Sampai pada puncak acara yaitu membuat test. Saya ingin melakukan test apakah saya berhasil mengirim POST request untuk membuat objek User Event. Saya juga perlu tahu apakah yang terjadi jika saya mengirim request dengan parameter yang tidak sesuai.
Untuk menguji saya perlu menjalankan client yang menembak url dan mengirimkan data. Hal ini dapat dilakukan dengan memanggil self.client Indikator yang dapat saya lihat untuk mengetahui apakah request berhasil adalah dari status code response. Sehingga, test saya menjadi seperti ini.
Tes di atas akan membuat POST request dengan parameter yang sesuai. Hasilnya akan diperiksa dengan melihat status code yaitu 201 (Created). Dapat dilihat bahwa saya tidak memeriksa apakah objek User Event benar-benar berhasil dibuat. Saya hanya menguji apakah dengan pemanggilan request tersebut berhasil dilakukan. Untuk masalah pembuatan objek User Event sudah ada test case nya sendiri sehingga test case tidak menjadi redundan.
Dalam prinsip F.I.R.S.T Principles of Unit Testing, ada satu konsep lagi yaitu huruf T yang berarti Thorough. Intinya adalah dalam menyusun testing, yang dikejar bukanlah tes dengan 100% code coverage … saja. Yang perlu diingat adalah apakah dengan menyusun tes ini saya bisa yakin bahwa aplikasi saya sudah menangani hal-hal yang tidak diinginkan. Salah satu penangannya adalah membuat test lain yang sifatnya ‘gagal’ yang disebut sebagai negative test.Oke, saya akan membuat sebuah negative test untuk skenario ini.
Salah satu contoh kasus yang dapat terjadi dan seharusnya gagal adalah saat uid dari user yang dikirim salah atau tidak terdaftar pada database. Karena saya belum membuat implementasi kodenya, saya bisa anggap terlebih dahulu jika saya mengirim uid yang tidak, maka status code akan menjadi 400 (bad request). Sehingga kode test secara lengkap menjadi seperti ini.
Dan test ini masih akan bertambah seiring saya mengerjakan implementasi kodenya. Setiap ada kasus baru yang diperkenalkan, saya harus menyiapkan test casenya. Saya ingin menyampaikan sepatah dua patah kata.
“Memang menyusun test itu merepotkan. Tapi lebih merepotkan lagi jika saya tidak tahu kode sebelah mana yang harus saya perbaiki.” — Saya
Saya rasa tulisan ini sudah cukup. Sampai jumpa di tulisan saya yang berikutnya. Semoga bermanfaat. Terima kasih.
Bye
— Muhammad Yudistira Hanifmuti
