Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. TDD
Code

Test-Driven Development Praktis

by
Difficulty:IntermediateLength:MediumLanguages:

Indonesian (Bahasa Indonesia) translation by Febri Ardian Sanjoyo (you can also view the original English article)

Apa itu Pengembangan Berdasarkan Uji Praktis?

Test-driven development (TDD) berarti Anda menulis tes Anda terlebih dahulu. Anda menetapkan harapan untuk kode yang benar di depan, sebelum Anda bahkan menulis satu baris logika bisnis. TDD tidak hanya membantu memastikan bahwa kode Anda benar, tetapi juga membantu Anda menulis fungsi yang lebih kecil, mem-refaktor kode Anda tanpa merusak functionality, dan memahami masalah Anda dengan lebih baik.

Dalam artikel ini, saya akan memperkenalkan beberapa konsep TDD dengan membangun small utility. Kita juga akan membahas beberapa skenario praktis di mana TDD akan membuat hidup Anda sederhana.

Membangun Klien HTTP dengan TDD

Apa yang Akan Kita Bangun

Kita akan secara bertahap membangun klien HTTP sederhana yang abstrak berbagai verba HTTP. Untuk membuat refactor halus, kita akan mengikuti praktik TDD. Kita akan menggunakan Jasmine, Sinon, dan Karma untuk pengujian. Untuk memulai, salin paket.json, karma.conf.js, dan webpack.test.js dari proyek contoh, atau hanya cloning proyek sampel dari repo GitHub.

Ini membantu jika Anda memahami cara kerja Fetch API baru, tetapi contohnya harus mudah diikuti. Untuk yang belum tahu, Fetch API adalah alternatif yang lebih baik untuk XMLHttpRequest. Ini menyederhanakan interaksi network dan bekerja dengan baik dengan Promises.

Wrapper Over GET

Pertama, buat file kosong di src/http.js dan file pengujian yang disertakan di bawah src/__test__/http-test.js.

Mari siapkan test environment untuk layanan ini.

Kita menggunakan Jasmine dan Sinon di sini — Jasmine untuk menentukan skenario pengujian dan Sinon untuk menegaskan dan memata-matai objek. (Jasmine punya cara sendiri untuk memata-matai dan berhenti mengerjakan tes, tapi aku lebih suka Sinon API.)

Kode di atas sudah cukup jelas. Sebelum setiap uji coba, kita membajak panggilan ke Fetch API, karena tidak ada server yang tersedia, dan mengembalikan mock promise object. Tujuannya di sini adalah untuk menguji unit jika Fetch API dipanggil dengan params dan melihat apakah wrapper mampu menangani kesalahan network dengan benar.

Mari mulai dengan kasus uji coba yang gagal:

Mulai test runner Anda dengan memanggil karma start. Tes jelas akan gagal sekarang, karena tidak ada metode get di http. Mari kita perbaiki itu.

Jika Anda menjalankan tes Anda sekarang, Anda akan melihat respons yang gagal mengatakan Expected [object Response] to equal Object({ }). Responsnya adalah objek Stream object. Objek-objek Stream, seperti namanya, masing-masing merupakan stream data. Untuk mendapatkan data dari stream, Anda perlu membaca stream terlebih dahulu, menggunakan beberapa metode helper. Untuk saat ini, kita dapat mengasumsikan bahwa stream akan JSON dan deserialize dengan memanggil response.json ().

Paket uji kita harus hijau sekarang.

Menambahkan Parameter Kueri

Sejauh ini, metode get hanya membuat panggilan sederhana tanpa params query. Mari tulis test yang gagal untuk melihat bagaimana seharusnya bekerja dengan parameter kuery. Jika kita melewatkan { users: [1, 2], limit: 50, isDetailed: false } sebagai params kuery, client HTTP kita harus membuat panggilan network ke /api/v1/users/?users=1&users=2&limit=50&isDetailed=false.

Sekarang setelah kita menyiapkan pengujian, mari kita memperluas metode get kita untuk menangani params kuery.

Jika params hadir, kita membuat string kuery dan menambahkannya ke URL.

Di sini saya telah menggunakan query-string library—ini adalah library little helperl yang membantu dalam menangani berbagai skenario params kuery.

Menangani Mutasi

GET mungkin merupakan metode HTTP yang paling sederhana untuk diterapkan. GET adalah idempoten, dan tidak boleh digunakan untuk mutasi apa pun. POST biasanya dimaksudkan untuk memperbarui beberapa catatan di server. Ini berarti bahwa permintaan POST memerlukan beberapa pagar di tempat secara default, seperti token CSRF. Lebih lanjut tentang itu di bagian selanjutnya.

Mari kita mulai dengan membuat tes untuk basic POST request:

Signature untuk POST sangat mirip dengan GET. Dibutuhkan properti options, di mana Anda dapat menentukan header, body dan, yang paling penting, method. Method ini menjelaskan HTTP verb—dalam hal ini, "post".

Untuk saat ini, mari kita asumsikan bahwa jenis kontennya adalah JSON dan mulai penerapan POST request.

Pada point ini, post mrthod kita sangat primitif. Tidak mendukung apa pun selain permintaan JSON.

Jenis Konten Alternatif dan Token CSRF

Mari izinkan caller untuk memutuskan type konten, dan melemparkan token CSRF ke dalam fray. Tergantung pada kebutuhan Anda, Anda dapat membuat CSRF opsional. Dalam kasus penggunaan kita, kita akan menganggap bahwa ini adalah fitur opt-in dan membiarkan penelepon menentukan apakah Anda perlu mengatur token CSRF di header.

Untuk melakukan ini, mulailah dengan mengirimkan options object sebagai parameter ketiga ke method kita.

Ketika kita menyediakan options dengan {contentType: http.HTTP_HEADER_TYPES.text,includeCsrf: true, itu harus mengatur header konten dan header CSRF yang sesuai. Mari perbarui fungsi post untuk mendukung options baru ini.

Perhatikan bahwa mendapatkan token CSRF merupakan detail implementation. Biasanya, itu bagian dari session cookie Anda, dan Anda dapat mengekstraknya dari sana. Saya tidak akan membahasnya lebih lanjut di artikel ini.

Test suite Anda seharusnya happy sekarang.

Encoding Forms

Method post kita mulai terbentuk sekarang, tetapi masih biasa ketika mengirim body. Anda harus message data Anda secara berbeda untuk setiap jenis konten. Ketika berhadapan dengan formulir, kita harus menyandikan data sebagai string sebelum mengirimnya melintasi wire.

Mari ekstrak method small heper untuk melakukan pengangkatan berat ini. Berdasarkan contentType, ia memproses data secara berbeda.

Lihat itu! Pengujian kita masih berjalan bahkan setelah refactoring komponen inti.

Handling PATCH Requests

Verb HTTP lain yang umum digunakan adalah PATCH. Sekarang, PATCH adalah panggilan mutasi, yang berarti bahwa signature dari dua tindakan ini sangat mirip. Satu-satunya perbedaan adalah dalam verb HTTP. Kita dapat menggunakan kembali semua test yang kita tulis untuk POST, dengan tweak sederhana.

Demikian pula, kita dapat menggunakan kembali metode post saat ini dengan membuat verb dapat dikonfigurasi, dan mengganti nama metode untuk mencerminkan sesuatu yang umum.

Sekarang setelah semua test POST kita lewat, semua yang tersisa adalah menambahkan metode lain untuk patch.

Sederhana, kan? Sebagai latihan, cobalah menambahkan request PUT atau DELETE Anda sendiri. Jika Anda stuck, silakan merujuk ke repo.

Ketika TDD?

Komunitas terbagi atas ini. Beberapa programmer menjalankan dan menyembunyikan saat mereka mendengar kata TDD, sementara yang lain hidup dengan itu. Anda dapat mencapai beberapa efek menguntungkan dari TDD hanya dengan memiliki test suite yang bagus. Tidak ada jawaban yang benar di sini. Ini semua tentang seberapa nyaman Anda dan tim Anda dengan pendekatan Anda.

Sebagai rule praktis, saya menggunakan TDD untuk masalah yang rumit dan tidak terstruktur yang saya butuhkan lebih jelas. Saat mengevaluasi pendekatan atau membandingkan beberapa pendekatan, saya merasa berguna untuk menentukan problem statement dan batas-batas di depan. Ini membantu dalam mengkristalisasi requirments dan edge cases yang perlu di handle oleh function Anda. Jika jumlah kasus terlalu tinggi, itu menunjukkan bahwa program Anda mungkin melakukan terlalu banyak hal dan mungkin sudah waktunya untuk membaginya menjadi unit yang lebih kecil. Jika persyaratannya mudah, saya lewati TDD dan tambahkan test nanti.

Menyimpulkan

Ada banyak noise di topik ini, dan mudah tersesat. Jika saya dapat meninggalkan Anda dengan beberapa saran perpisahan: jangan terlalu khawatir tentang TDD itu sendiri, tetapi fokuslah pada prinsip-prinsip yang mendasarinya. Ini semua tentang menulis kode yang bersih, mudah dimengerti, dan bisa dipelihara. TDD adalah keterampilan yang berguna dalamtool belt programmer. Seiring waktu, Anda akan mengembangkan intuisi tentang kapan harus menerapkan ini.

Terima kasih telah membaca, dan beri tahu kami pendapat Anda di bagian komentar.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.