Kami ingin menarik perhatian Anda pada satu lagi hal baru yang tersedia di pra-pemesanan kami - buku tentang pengujian unit .
Penulis publikasi hari ini secara singkat dan jelas berbicara tentang keuntungan pengujian unit dan TDD menggunakan front-end sebagai contoh.
Selamat membaca!
Pengujian unit adalah salah satu pendekatan terpenting yang harus dilakukan setiap pengembang. Namun, saya telah melihat banyak proyek yang sulit untuk menerapkan pengujian unit. Ada beberapa alasan untuk ini. Misalnya, seseorang mungkin mengatakan bahwa Anda perlu fokus pada pengembangan fitur, dan menulis pengujian unit dalam hal ini merupakan beban tambahan yang serius. Orang lain akan memperhatikan bahwa menguji kode mereka bukanlah hal yang sepele karena kode itu sendiri rumit. Dalam kedua kasus ini, intinya terlewatkan.
Saya ingat ungkapan ini: ketika memikirkan apakah Anda punya waktu untuk menulis pengujian unit, pikirkan apakah Anda akan memiliki waktu ekstra untuk memproses kode yang sama dua kali, karena bug dan masalah yang akan muncul di dalamnya.
Menulis Kode yang Dapat Diuji
Pertama, mari kita tentukan kesalahan umum apa yang membuat pengujian kode Anda lebih sulit. Ketika sampai pada pengujian front-end, salah satu masalah tersulit yang saya ketahui adalah menguji komponen antarmuka pengguna. Masalah utama yang saya temui dalam hal ini adalah: kebetulan komponennya terlalu "pintar" dan digantung dengan ketergantungan pada fragmen kode lain, misalnya, dari panggilan API, pemuatan data, penanganan acara, dan implementasi logika bisnis. Banyak pengembang tidak suka menulis tes untuk komponen "berat" seperti itu.
Solusi paling sederhana untuk masalah ini adalah memisahkan komponen ke dalam logika dan presentasi. Dengan pemisahan ini, Anda dapat menguji bagaimana komponen presentasi mematuhi logika presentasi, melakukan pemrosesan dan rendering acara, dan fokus secara terpisah pada pengujian logika bisnis di komponen yang bertanggung jawab atas logika tersebut.
Memastikan bahwa komponen Anda dapat diuji juga merupakan cara yang baik untuk memastikan bahwa komponen tersebut independen, dapat digunakan kembali, dan nyaman digunakan bersama. Ini sangat penting, terutama saat berbagi komponen di seluruh proyek menggunakan alat dan platform populer seperti Bit ( Github). Biasanya, Bit akan menampilkan dan menguji setiap komponen Anda secara terpisah, dan hanya kemudian mengirimkannya ke koleksi bersama, sehingga memastikan bahwa mereka memang dapat digunakan kembali - jika tidak, apa gunanya membuatnya dapat dipisahkan.
Contoh: Menjelajahi Komponen Reaksi yang Dapat Digunakan Kembali yang Dibagikan di Bit.dev
Lingkaran setan: apa yang terjadi jika Anda tidak menulis tes unit
Dari pengalaman saya dengan tim yang tidak menerapkan pengujian unit dengan benar (yaitu, tidak menggunakan cakupan pengujian sebagai metrik) baik memulai pengujian unit terlalu terlambat, atau dari awal, tetapi tidak mempelajari cara mempraktikkannya. Mungkin ada banyak alasan untuk ini, tetapi saya akan memberikan beberapa contoh untuk memudahkan Anda memutuskan mana yang paling mirip dengan kasus Anda.
Bagaimana kami menguji kode kami selama pengembangan
Menurut pendapat saya, kecuali Anda tetap menggunakan pengembangan yang digerakkan oleh pengujian (TDD), fungsionalitas dapat dikembangkan asalkan frontend terus dimuat di browser. Anda perlu fokus pada visualisasi fungsionalitas dan interaksi yang terjadi di antarmuka pengguna, karena ini adalah inti dari pengembangan sisi klien.
Hanya setelah itu, ketika semua fungsionalitas sudah berfungsi, penekanannya bergeser ke pengujian unit.
Inilah masalah utama yang harus Anda hadapi: menulis pengujian unit adalah pekerjaan tambahan yang dilakukan setelah pengembangan fungsionalitas selesai. Pendekatan ini mengarah pada kesan bahwa pengujian unit adalah tugas tambahan yang dilakukan di atas pengembangan fungsionalitas yang sudah jadi.
Karena rumusan pertanyaan ini, baik pemilik produk dan pengembang mengklasifikasikan pengujian unit sebagai biaya.
Tapi, jika Anda tetap berpegang pada TDD, maka semuanya berkembang justru sebaliknya. Karena kasus pengujian ditulis sebelumnya, kami tidak perlu memeriksa semuanya dengan terus-menerus memvisualisasikan perubahan, karena kami memiliki cara berbeda untuk memeriksa kode selama pengembangan. Dalam hal ini, alat verifikasi utama adalah menulis kode yang akan lulus uji kasus unit.
Oleh karena itu, saya percaya bahwa praktik TDD adalah tahapan terpenting sebelum praktik tes unit.
Seberapa sering pengujian unit dijalankan
Anda mungkin bertanya-tanya bagaimana menjalankan pengujian unit memengaruhi bagaimana pengujian unit ditulis. Misalnya, Anda memiliki satu set pengujian lengkap. Anda membuangnya dari waktu ke waktu. Oleh karena itu, pengembang jarang yakin akan kegunaannya. Selain itu, bahkan saat tes ditemukan gagal, sudah terlambat.
Oleh karena itu, penting untuk menjalankan pengujian unit setidaknya di setiap tahap build permintaan tarik. Dengan mengikuti praktik yang diambil dari DevOps ini, kami memastikan bahwa setiap blok kode baru yang kami tambahkan melewati serangkaian pengujian unit. Bahkan jika ada kebutuhan untuk mengubah kasus tertentu, pengembang akan melakukannya sebelum tindakan penggabungan kode.
Seberapa sering untuk mengukur cakupan kode dengan tes
Seperti eksekusi uji, pengukuran ini juga penting baik secara psikologis maupun sebagai praktik bagi pengembang untuk menilai apakah mereka menyiapkan kasus uji yang cukup untuk mencakup semua kode tertulis.
Dalam hal ini, saya yakin dasbor saja tidak cukup, di mana Anda dapat melihat cakupan pengujian unit. Tetapi, jika dimungkinkan untuk menambahkan tindakan pengukuran saat menambahkan kode baru dan dengan demikian memeriksa tingkat cakupan pengujian, maka alternatif seperti itu akan lebih mudah untuk mendapatkan umpan balik instan. Kami bahkan dapat merumuskan aturan yang mewajibkan kode baru yang ditambahkan ke database harus dicakup oleh pengujian, katakanlah, 80%. Paling tepat untuk menambahkan validasi ini ke proses build permintaan pull.
Karena pengembang menerima umpan balik instan tentang cakupan pengujian unit kode mereka, mereka bebas untuk mengambil langkah-langkah untuk mengejar cakupan seperti yang diperlukan.
Keluar dari lingkaran ini
Jika Anda sudah terlibat dalam lingkaran setan ini, maka cara terbaik untuk keluar darinya adalah dengan memperkuat praktik yang dibahas di atas. Karena hal di atas adalah tentang pengujian yang sering untuk memvalidasi kode yang baru ditambahkan, serta menguji cakupan kode baru, Anda dapat mengembangkan prosedur yang sesuai untuk setiap operasi penambahan atau pengubahan kode.
Sangat tidak mungkin bahwa Anda akan memiliki cukup waktu untuk mencakup semua kode lama dengan tes (kecuali proyek itu sendiri benar-benar baru) segera, sebelum Anda harus menulis kode baru. Karena itu, jangan mengandalkan ini sama sekali, karena dari sudut pandang bisnis, ini tidak praktis.Sementara itu, Anda dapat melakukan pengukuran berkala, yang secara strategis mencakup bagian tertentu dari kode lama dengan pengujian. Yang terpenting, Anda harus melatih semua pengembang untuk mengikuti praktik ini. Sama pentingnya untuk tidak membiasakan diri dengan menganggap pekerjaan ini sebagai biaya dan untuk menyampaikan kepada semua pemilik proyek betapa pentingnya menulis pengujian unit. Jika tidak, mungkin bagi banyak orang, terutama non-teknisi, pengujian unit adalah pekerjaan yang tidak perlu, alih-alih menghabiskan waktu untuk mengembangkan fungsionalitas baru.
Jadi apa nilai sebenarnya dari semua pekerjaan ini
Tes unit berguna dalam banyak hal. Jika diterapkan dengan benar, mereka membantu mengurangi jumlah cacat dalam kode, bertindak sebagai jaminan saat menguji fungsionalitas yang ada, tidak rusak saat melakukan pemfaktoran ulang kode, dan juga membantu menjaga produktivitas keseluruhan pada tingkat tinggi.
Dengan melihat kode yang dicakup dengan baik oleh pengujian unit, semua orang dapat melihat seberapa yakin tampilannya.Jadi, mari kita isi celahnya dan kembali ke jalurnya dengan mengadopsi praktik DevOps dan membiasakan diri menulis pengujian unit yang baik sambil tetap berpegang pada pengembangan yang digerakkan oleh pengujian.