BerandaComputers and TechnologyMenguji Aplikasi JavaScript dengan percaya diri

Menguji Aplikasi JavaScript dengan percaya diri

Tidak dapat disangkal bahwa banyak hal yang berubah dalam beberapa tahun terakhir di dunia JavaScript. Ini seharusnya tidak mengejutkan. Kami sangat senang melihat banyak kemajuan dalam cara kami menulis dan berpikir tentang pengujian di ekosistem JavaScript.

Jika kami mengambil sedikit mundur, sekitar 3–4 tahun yang lalu pemandangannya sudah menjanjikan. Pelari pengujian seperti Jest sudah cukup populer, memberikan Pengalaman Pengembang yang baik, dan menguji komponen React cukup banyak ditentukan oleh Enzim .

Kami di commercetools sangat senang dengan perkakas yang kami miliki dan kami mencoba membuat beberapa praktik terbaik di tim kami tentang cara menulis pengujian unit yang baik. Kami menulis tentang itu di artikel ini: Pengujian di React: praktik terbaik, tip dan trik .

Namun, jika saya membaca ulang ini sekarang, reaksi saya adalah tidak menyetujui sebagian besar artikel yang berkhotbah. Ya sungguh, karena ini hanya menunjukkan seberapa banyak hal telah berubah sejak itu.

Untungnya mereka telah berubah menjadi lebih baik ! Mari kita lihat apa yang sebenarnya telah berubah.

Kami telah menyebutkan sebelumnya bahwa kami memiliki alat pengujian yang baik di pembuangan. Apa yang kami yakini kurang adalah mentalitas mendasar tentang bagaimana kita harus mendekati penulisan dan pemikiran tentang pengujian.

Berkat upaya komunitas, dan ajaran Kent C. Dodds , cara kami menguji Aplikasi JavaScript telah berubah secara radikal.

Semakin mirip pengujian Anda dengan cara perangkat lunak Anda digunakan, semakin percaya diri mereka dapat memberi Anda.

Kuncinya adalah bagaimana caranya kami memikirkan tentang apa yang perlu diuji. Secara tradisional, sebagian besar dari kita (kami asumsikan) menulis pengujian yang juga menguji sebagian besar internal, misalnya, komponen UI, yang menyebabkan frustrasi dan masalah saat harus melakukan refactor kode, karena implementasi dan pengujian harus diubah. Bagaimanapun, salah satu alasan utama menulis tes adalah agar dapat mengubah implementasi di masa depan dengan percaya diri.

Akibatnya, tes seharusnya hanya memperhatikan apa yang dilihat dan dapat berinteraksi dengan pengguna akhir . Oleh karena itu, pengujian bersifat agnostik terhadap detail implementasi, sehingga memungkinkan pemfaktoran ulang yang jauh lebih percaya diri karena hanya implementasinya yang perlu diubah, bukan hasil akhirnya dan juga pengujian.

Untuk membantu mengikuti mentalitas ini dan menegakkan praktik terbaik, DOM Testing Library & Co. lahir.

Jika Anda ingin tahu lebih banyak tentang topik ini, lihat sumber daya berikut:

Untuk kami di commercetools ini sangat membantu untuk memikirkan kembali dan mengevaluasi kembali bagaimana kita ingin menulis tes. Yang terpenting, kami telah melihat manfaat berikut:

  • Kami memiliki lebih banyak kepercayaan saat memfaktorkan ulang kode yang ada atau mengimplementasikan fitur baru, karena kami dapat mengandalkan pengujian stabil.
  • Kami tidak menulis pengujian untuk setiap komponen tetapi lebih pada tingkat aplikasi, memberi kami cakupan yang lebih mendalam tentang apa yang sedang diuji. Ini secara implisit membantu kami untuk juga menguji hal-hal seperti perutean.
  • Pustaka Pengujian DOM mempromosikan penulisan dan pengujian komponen yang dapat diakses .

Jest sudah menyediakan sistem ejekan yang baik. Namun, ini menyisakan banyak ruang untuk menguji pengambilan data dalam komponen.

Kami di commercetools terutama menggunakan GraphQL dan Apollo, terutama di aplikasi frontend kami.
Apollo memiliki Komponen Penyedia Mocked yang dapat digunakan untuk meniru kueri GraphQL. Ini sangat berguna saat menguji berbagai hal di tingkat aplikasi dan pada gilirannya berfungsi sangat baik dengan pendekatan Perpustakaan Pengujian DOM.

Namun, mengejek kueri GraphQL dengan Apollo Penyedia yang Diolok-olok telah menunjukkan kelemahannya sendiri. Salah satu alasannya adalah bahwa permintaan pencocokan bisa menjadi sangat bertele-tele dan skenario yang berbeda sulit dibedakan, seperti memiliki sebagian data, atau kode status HTTP yang berbeda. Hal ini sebagian karena sifat tidak dapat mengejek cukup dekat ke tingkat jaringan, karena bergantung pada Apollo itu sendiri.

Kami juga dapat berargumen bahwa menggunakan tiruan Apollo perlu diketahui detail implementasi permintaan, yang idealnya bukan yang seharusnya kita tuju (seperti yang disebutkan sebelumnya).

Oleh karena itu, opsi yang lebih baik adalah mengejek secara langsung di tingkat jaringan dan sehingga menghilangkan kebutuhan Apollo untuk mendikte perilaku mengejek. Menggunakan perpustakaan seperti xhr-mock kami dapat mencegat permintaan dan menanganinya sesuai dengan aturan pencocokan yang telah ditentukan. Misalnya untuk permintaan GraphQL, kami dapat mencocokkan kueri GraphQL dengan nama operasinya. Apollo juga menawarkan alat untuk secara otomatis membuat data tiruan berdasarkan skema GraphQL.

Pendekatan ini lebih sejalan dengan mentalitas pengujian bagaimana aplikasi berperilaku daripada bagaimana aplikasi diimplementasikan.

Pekerja Layanan Mock

Untungnya, agar lebih mudah untuk diejek permintaan di tingkat jaringan, ada perpustakaan baru yang disebut Pekerja Layanan Mock (MSW).

Dengan menghadirkan kemampuan Service Worker untuk menangkap permintaan untuk tujuan caching, Layanan Mock Worker mengaktifkan pemalsuan API pada level tertinggi rantai komunikasi jaringan. Ini adalah hal yang paling dekat dengan server tiruan tanpa harus membuatnya.

Kami di commercetools telah mencari dan mencoba perpustakaan ini di masa lalu berbulan-bulan dan sejauh ini kami sangat senang dengannya.
Kami telah menemukan bahwa pengaturan pengujian untuk memalsukan permintaan jaringan jauh lebih sederhana, misalnya, menggunakan tiruan Apollo. Ini juga berfungsi untuk permintaan GraphQL dan REST, sehingga pendekatan tiruan yang sama dapat digunakan untuk keduanya. Terakhir, MSW dapat digunakan di browser dan lingkungan Node.js, menghilangkan kebutuhan untuk mengetahui dan menggunakan pustaka yang berbeda.

Bermigrasi untuk menggunakan MSW juga cukup mulus karena yang harus kami lakukan hanyalah mengganti pengaturan mock permintaan dan pengujian tetap berfungsi seperti sebelumnya.

Selain itu, selain beberapa fitur bagus dari MSW, gagasan inti dari MSW mengikuti prinsip pengujian yang sama yang telah kita diskusikan sebelumnya: menguji bagaimana aplikasi berperilaku daripada bagaimana itu dibangun .

Daripada menegaskan bahwa permintaan telah dibuat, atau memiliki data yang benar, uji bagaimana aplikasi Anda bereaksi terhadap permintaan tersebut.

Namun, kami masih dapat melakukan validasi permintaan masuk dengan mengirim respons kesalahan .

Kami hanya dapat merekomendasikan untuk memeriksanya dan mencobanya.

Data uji

Aspek penting lainnya dari pengujian adalah tentang data pengujian yang mendasarinya. Seringkali Anda akhirnya menulis data “palsu” yang sama dalam banyak pengujian, mungkin juga menghilangkan bidang tertentu karena tidak digunakan dalam skenario pengujian tertentu. Selain itu, datanya mungkin tidak mencakup skenario dunia nyata, sehingga membuat sebagian besar pengujian hampir tidak berarti.

Proses ini sangat bertele-tele dan rawan kesalahan dan kami di commercetools telah mengalami masalah ini lebih dan lebih dalam beberapa tahun terakhir. Dengan meningkatnya jumlah API di platform kami, harus mempertahankan pengujian sedemikian rupa tidak dapat diskalakan sama sekali.

Jadi kami memutuskan untuk mengatasi masalah ini dan memulai inisiatif untuk menghasilkan tes data.
Singkatnya, idenya adalah bahwa setiap entitas di API platform kami didefinisikan sebagai model data uji. Sebuah model berisi semua bidang yang tersedia untuk entitas itu, yang sebagian besar dihasilkan sebagai nilai acak menggunakan

pemalsu

Perpustakaan.
Kami juga memiliki konsep yang disebut transformator di mana kami dapat memperoleh representasi yang berbeda dari model dasar, misalnya untuk bentuk mirip GraphQL atau REST.

Menggabungkan ini dengan alat pengujian seperti DOM Testing Library dan MSW menghasilkan kombinasi yang sangat kuat yang membuat pengaturan tes lebih sederhana sehingga kami dapat lebih fokus pada hal yang penting: menulis tes yang andal dengan percaya diri.

Pendekatan yang Anda lakukan pada testin g aplikasi Anda sangat penting dan yang terpenting tes harus membantu Anda dan tim Anda untuk memiliki tingkat yang tepat kepercayaan diri daripada menghalangi.

Di commercetools kami sangat senang dengan cara kami terus berupaya meningkatkan pendekatan pengujian kami, karena pendekatan ini telah terbukti berguna berkali-kali dan telah membantu kami menjadi lebih produktif dan ya, lebih percaya diri. Memiliki tingkat kepercayaan yang baik juga memungkinkan kami melakukan hal-hal seperti penerapan berkelanjutan (rangkaian penerapan).

Jika sebagian besar dari ini terdengar baru bagi Anda, kami sangat menyarankan agar Anda mulai memikirkan kembali bagaimana Anda dapat mendekati pengujian aplikasi dan komponen UI, dan memilih alat yang disarankan untuk membantu Anda menulis pengujian yang tangguh dan bermakna .
Yang paling penting , Anda tidak perlu menulis ulang semuanya sekaligus. Misalnya, kami merekomendasikan menulis ulang pengujian dari awal berdasarkan skenario pengujian yang ada dan menghapus semua pengujian sebelumnya yang terkait dengan fungsionalitas tersebut, daripada mencoba menulis ulang pengujian sebelumnya.

Misalnya, kami masih memiliki bagian dari basis kode kami yang menggunakan “pendekatan pengujian lama” dan yang menyebabkan masalah dari waktu ke waktu waktu. Setiap kali kami memiliki kesempatan, kami menulis pengujian untuk bagian fungsionalitas itu sebagai pengujian baru dan menghapus file pengujian sebelumnya. Selamat menguji!

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments