Advertisement
  1. Code
  2. Tools & Tips

Pengujian di Node.js

by
Difficulty:BeginnerLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Hasannudin Amin (you can also view the original English article)

Siklus pengembangan yang didorong oleh pengujian menyederhanakan proses berpikir menulis kode, membuatnya lebih mudah, dan lebih cepat dalam jangka panjang. Tetapi hanya menulis tes saja tidak cukup dengan sendirinya, mengetahui jenis-jenis tes yang harus ditulis dan bagaimana menyusun kode agar sesuai dengan pola ini adalah tentang apa itu semua. Dalam artikel ini kita akan melihat membangun aplikasi kecil di Node.js mengikuti pola TDD.

Selain tes 'unit' sederhana, yang kita semua kenal; Kita juga dapat memiliki Node.js Async code running, yang menambahkan dimensi tambahan di mana kita tidak selalu tahu urutan di mana fungsi akan berjalan atau kita mungkin mencoba menguji sesuatu di callback atau memeriksa untuk melihat bagaimana fungsi async berfungsi.

Dalam artikel ini kita akan membangun aplikasi Node yang dapat mencari file yang cocok dengan permintaan yang diberikan. Saya tahu sudah ada hal-hal untuk ini (ack) tetapi demi mendemonstrasikan TDD, saya pikir ini bisa menjadi proyek yang baik.

Langkah pertama adalah jelas untuk menulis beberapa tes, tetapi bahkan sebelum itu, kita perlu memilih kerangka pengujian. Anda dapat menggunakan Node vanila, karena ada pustaka yang terpasang di dalamnya, tetapi tidak banyak dalam hal pelari uji, dan cukup banyak hal penting.

Pilihan lain dan mungkin favorit saya untuk penggunaan umum adalah Jasmine. Ini cukup mandiri, Anda tidak memiliki dependensi lain untuk ditambahkan ke skrip Anda dan sintaksnya sangat bersih dan mudah dibaca. Satu-satunya alasan saya tidak akan menggunakan ini hari ini, adalah karena saya pikir Jack Franklin melakukan pekerjaan yang sangat baik yang meliputi ini dalam seri Tuts+ baru-baru ini di sini, dan itu baik untuk mengetahui pilihan Anda sehingga Anda dapat memilih alat terbaik untuk situasi Anda.


Apa yang Akan Kita Bangun

Dalam artikel ini kita akan menggunakan pelari uji 'Mocha' fleksibel bersama dengan pustaka pernyataan Chai.

Tidak seperti Jasmine yang lebih seperti seluruh rangkaian uji dalam satu paket, Mocha hanya mengurus keseluruhan struktur tetapi tidak ada hubungannya dengan pernyataan yang sebenarnya. Hal ini memungkinkan Anda untuk menjaga tampilan dan nuansa yang konsisten saat menjalankan tes, tetapi juga memungkinkan Anda untuk menjalankan pustaka pernyataan mana yang paling sesuai dengan situasi Anda.

Jadi misalnya, jika Anda akan menggunakan pustaka vanili 'asertif', Anda bisa memasangkannya dengan Mocha untuk menambahkan beberapa struktur pada pengujian Anda.

Chai adalah pilihan yang cukup populer, dan juga semua tentang opsi dan modularitas. Bahkan tanpa plugin apa pun, hanya dengan menggunakan API default, Anda memiliki tiga sintaks yang berbeda yang dapat Anda gunakan bergantung pada apakah Anda ingin menggunakan gaya TDD yang lebih klasik atau sintaks BDD yang lebih verbose.

Jadi sekarang kita tahu apa yang akan kita gunakan, mari masuk ke instalasi.


Pengaturan

Untuk memulai, mari instal Mocha secara global dengan menjalankan:

Ketika itu selesai membuat folder baru untuk proyek kami dan jalankan yang berikut di dalamnya:

Ini akan menginstal salinan lokal Chai untuk proyek kami. Selanjutnya, buat folder bernama test di dalam direktori proyek kami, karena ini adalah lokasi default Mocha akan mencari tes.

Itu cukup banyak untuk setup, langkah selanjutnya adalah untuk berbicara tentang bagaimana struktur aplikasi Anda ketika mengikuti proses pengembangan tes didorong.


Menata Aplikasi Anda

Penting untuk diketahui, ketika mengikuti pendekatan TDD, apa yang perlu diuji dan mana yang tidak. Aturan praktisnya adalah tidak menulis tes untuk kode lain yang sudah diuji. Yang saya maksudkan dengan ini adalah sebagai berikut: katakanlah kode Anda membuka file, Anda tidak perlu menguji fungsi fs individu, itu adalah bagian dari languge dan seharusnya sudah teruji dengan baik. Hal yang sama terjadi ketika menggunakan pustaka pihak ketiga, Anda tidak boleh menyusun fungsi yang terutama memanggil jenis fungsi ini. Anda tidak benar-benar menulis tes untuk ini dan karena ini Anda memiliki kesenjangan dalam siklus TDD.

Sekarang tentu saja, dengan setiap gaya pemrograman ada banyak pendapat yang berbeda dan orang-orang akan memiliki pandangan yang berbeda tentang bagaimana TDD. Tetapi pendekatan yang saya gunakan adalah bahwa Anda membuat komponen individual untuk digunakan dalam aplikasi Anda, yang masing-masing memecahkan masalah fungsional yang unik. Komponen-komponen ini dibangun menggunakan TDD memastikan bahwa mereka bekerja seperti yang diharapkan dan Anda tidak akan merusak API mereka. Kemudian Anda menulis skrip utama Anda, yang pada dasarnya semua kode lem, dan tidak perlu diuji / tidak dapat diuji, dalam situasi tertentu.

Ini juga berarti bahwa sebagian besar komponen Anda dapat digunakan kembali di masa depan karena tidak banyak yang harus dilakukan, langsung, dengan skrip utama.

Mengikuti apa yang baru saja saya katakan, ini adalah praktik umum untuk membuat folder bernama 'lib' di mana Anda meletakkan semua komponen individual. Jadi sampai titik ini Anda harus menginstal Mocha dan Chai, dan kemudian direktori proyek dengan dua folder: 'lib' dan 'test'.


Memulai Dengan TDD

Hanya jika Anda baru mengenal TDD, saya pikir itu akan menjadi ide yang baik untuk cepat menutup proses. Aturan dasarnya adalah Anda tidak dapat menulis kode apa pun kecuali pelari uji memberi tahu Anda.

Pada dasarnya, Anda menulis apa yang seharusnya dilakukan oleh kode Anda sebelum benar-benar melakukannya. Anda memiliki tujuan yang benar-benar terfokus saat mengkode dan Anda tidak pernah berkompromi dengan ide Anda dengan mendapatkan sisi-dilacak atau berpikir terlalu jauh ke depan. Selain itu, karena semua kode Anda akan memiliki tes yang terkait dengannya Anda dapat yakin bahwa Anda tidak akan pernah merusak aplikasi Anda di masa mendatang.

Sebuah tes, dalam kenyataannya, hanyalah sebuah deklarasi dari fungsi apa yang diharapkan untuk dilakukan ketika dijalankan, Anda kemudian menjalankan pelari pengujian Anda, yang jelas akan gagal (karena Anda belum menulis kode) dan kemudian Anda menulis jumlah minimum kode yang diperlukan untuk lulus tes gagal. Sangat penting untuk tidak melewati langkah ini, karena terkadang sebuah tes akan berlalu bahkan sebelum Anda menambahkan kode apa pun, karena kode lain yang Anda miliki di kelas atau fungsi yang sama. Ketika ini terjadi, Anda juga menulis lebih banyak kode maka Anda seharusnya untuk tes yang berbeda atau ini hanya tes yang buruk (biasanya tidak cukup spesifik).

Sekali lagi sesuai dengan aturan kami di atas, jika tes langsung lolos Anda tidak dapat menulis kode apa pun, karena itu tidak memberitahu Anda. Dengan terus menulis tes dan kemudian menerapkan fitur-fitur Anda membangun modul-modul solid yang dapat Anda andalkan.

Setelah Anda selesai menerapkan dan menguji komponen Anda, Anda dapat kembali dan mem-refactor kode untuk mengoptimalkannya dan membersihkannya tetapi memastikan refactoring tidak gagal dari tes yang Anda miliki dan yang lebih penting, tidak t menambahkan semua fitur yang belum diuji.

Setiap perpustakaan pengujian akan memiliki sintaks sendiri, tetapi mereka biasanya mengikuti pola yang sama untuk membuat pernyataan dan kemudian memeriksa apakah mereka lulus. Karena kami menggunakan Mocha dan Chai, mari kita lihat sintaks mereka dimulai dengan Chai.


Mocha & Chai

Saya akan menggunakan sintaks BDD 'Expect', karena seperti yang saya sebutkan, Chai hadir dengan beberapa opsi out of the box. Cara sintaks ini bekerja adalah Anda mulai dengan memanggil fungsi expect, memberikan objek yang ingin Anda buat pernyataan, dan kemudian Anda rangkai dengan tes khusus. Contoh apa yang saya maksud bisa sebagai berikut:

Itulah sintaks dasar, kami mengatakan mengharapkan penambahan 4 dan 5 sama dengan 9. Sekarang ini bukan tes yang bagus karena 4 dan 5 akan ditambahkan oleh Node.js sebelum fungsi ini disebut sehingga kami pada dasarnya menguji kemampuan matematika saya, tapi saya harap Anda mendapatkan ide umum. Hal lain yang harus Anda perhatikan, adalah sintaks ini tidak mudah dibaca, dalam hal aliran kalimat bahasa Inggris normal. Mengetahui hal ini, Chai menambahkan rantai getter berikut yang tidak melakukan apa pun tetapi Anda dapat menambahkannya untuk membuatnya lebih verbose dan dapat dibaca. Rantai getter adalah sebagai berikut:

  • to
  • be
  • been
  • is
  • that
  • and
  • have
  • with
  • at
  • of
  • same
  • a
  • an

Dengan menggunakan di atas, kita dapat menulis ulang tes kami sebelumnya ke sesuatu seperti ini:

Saya sangat menyukai nuansa seluruh perpustakaan, yang dapat Anda lihat di API mereka. Hal-hal sederhana seperti meniadakan operasi semudah menulis. Tidak sebelum ujian:

Jadi bahkan jika Anda belum pernah menggunakan perpustakaan sebelumnya, tidak akan sulit untuk mengetahui apa yang sedang dilakukan tes.

Hal terakhir yang saya ingin lihat sebelum kita masuk ke pengujian pertama adalah bagaimana kita menyusun kode kita di Mocha

Mocha

Mocha adalah pelari uji, jadi tidak terlalu peduli dengan tes yang sebenarnya, yang perlu diperhatikan adalah struktur tes, karena itu adalah bagaimana ia tahu apa yang gagal dan bagaimana menata hasilnya. Cara Anda membangunnya, adalah Anda membuat beberapa blok describe yang menguraikan berbagai komponen pustaka Anda dan kemudian Anda tambahkan blok it untuk menentukan uji tertentu.

Untuk contoh cepat, katakanlah kita memiliki kelas JSON dan kelas itu memiliki fungsi untuk mengurai JSON dan kami ingin memastikan fungsi parse dapat mendeteksi string JSON yang diformat dengan buruk, kita dapat menyusunnya seperti ini:

Ini tidak rumit, dan itu sekitar 80% preferensi pribadi, tetapi jika Anda mempertahankan format semacam ini, hasil tes harus keluar dalam format yang sangat mudah dibaca.

Kami sekarang siap untuk menulis pustaka pertama kami, mari kita mulai dengan modul sinkron sederhana, agar kita lebih mengenal sistem. Aplikasi kami harus dapat menerima opsi baris perintah untuk mengatur hal-hal seperti berapa banyak tingkat folder yang harus dicari aplikasi kami dan kueri itu sendiri.

Untuk mengatasi semua ini, kita akan membuat modul yang menerima string perintah dan mem-parsing semua opsi yang disertakan beserta nilainya.

Modul Tag

Ini adalah contoh bagus dari modul yang dapat Anda gunakan kembali di semua aplikasi baris perintah Anda, karena masalah ini sering muncul. Ini akan menjadi versi yang disederhanakan dari paket aktual yang saya miliki pada npm yang disebut ClTags. Jadi untuk memulai, buat file bernama tags.js di dalam folder lib, dan kemudian file lain bernama tagsSpec.js di dalam folder pengujian.

Kita perlu menarik Chai mengharapkan fungsi, karena itu akan menjadi sintaks pernyataan yang akan kita gunakan dan kita perlu menarik file tag yang sebenarnya sehingga kita dapat mengujinya. Secara keseluruhan dengan beberapa pengaturan awal seharusnya terlihat seperti ini:

Jika Anda menjalankan perintah 'mocha' sekarang dari akar proyek kami, semuanya harus lewat seperti yang diharapkan. Sekarang mari kita pikirkan tentang apa yang akan dilakukan modul kita; kami ingin mengirimkannya deretan argumen perintah yang digunakan untuk menjalankan aplikasi, dan kemudian kami menginginkannya untuk membangun objek dengan semua tag, dan alangkah baiknya jika kami juga dapat meneruskannya ke objek default dari pengaturan, jadi jika tidak ada yang ditimpa, kami akan memiliki beberapa pengaturan yang sudah tersimpan.

Ketika berhadapan dengan tag, banyak aplikasi juga menyediakan opsi pintasan yang hanya satu karakter, jadi katakanlah kami ingin mengatur kedalaman pencarian kami, kami dapat memungkinkan pengguna untuk menentukan sesuatu seperti --depth=2 atau sesuatu seperti -d=2 yang seharusnya memiliki efek yang sama.

Jadi mari kita mulai dengan tag panjang yang terbentuk (misalnya, '--depth=2'), Untuk memulai, mari tulis tes pertama:

Kami menambahkan satu metode ke rangkaian uji kami yang disebut parse dan kami menambahkan tes untuk tag yang panjang. Di dalam tes ini saya membuat contoh perintah dan menambahkan dua pernyataan untuk dua properti yang harus diambilnya.

Menjalankan Mocha sekarang, Anda harus mendapatkan satu kesalahan, yaitu bahwa tags tidak memiliki fungsi parse. Jadi untuk memperbaiki kesalahan ini mari tambahkan fungsi parsing ke modul tag. Cara yang lumayan khas untuk membuat modul node seperti ini:

Kesalahan mengatakan kami membutuhkan metode parse sehingga kami membuatnya, kami tidak menambahkan kode lain di dalamnya karena belum memberitahu kami. Dengan bertahan dengan minimal Anda yakin bahwa Anda tidak akan menulis lebih dari yang seharusnya dan berakhir dengan kode yang belum teruji.

Sekarang mari kita jalankan Mocha lagi, kali ini kita harus mendapatkan kesalahan yang mengatakan kepada kita bahwa itu tidak dapat membaca properti yang bernama depth dari variabel yang tidak terdefinisi. Itu karena saat ini fungsi parse kita tidak mengembalikan apa-apa, jadi mari tambahkan beberapa kode sehingga akan mengembalikan objek:

Kami perlahan-lahan bergerak, jika Anda menjalankan Mocha lagi, seharusnya tidak ada pengecualian apa pun yang dilempar, hanya pesan kesalahan bersih yang mengatakan bahwa objek kosong kami tidak memiliki properti yang disebut depth.

No depth property

Sekarang kita bisa masuk ke beberapa kode nyata. Untuk fungsi kami untuk menguraikan tag dan menambahkannya ke objek kami, kami perlu menggilir array argumen dan menghapus tanda ganda di awal kunci.

Kode ini berputar melalui daftar argumen, memastikan kita berhadapan dengan tag yang sudah lama terbentuk, lalu membaginya dengan karakter equals pertama untuk membuat pasangan kunci dan nilai untuk objek opsi.

Sekarang ini hampir menyelesaikan masalah kami, tetapi jika kami menjalankan Mocha lagi, Anda akan melihat bahwa kami sekarang memiliki kunci untuk kedalaman, tetapi ini diatur ke string, bukan angka. Angka-angka agak sedikit lebih mudah untuk dikerjakan nanti di aplikasi kami, jadi bagian kode berikutnya yang perlu kami tambahkan adalah mengonversi nilai ke angka jika memungkinkan. Ini dapat dicapai dengan beberapa RegEx dan fungsi parseInt sebagai berikut:

Menjalankan Mocha sekarang, Anda harus mendapatkan lulus dengan satu tes. Konversi angka harus bisa dibilang dalam pengujian sendiri, atau setidaknya disebutkan dalam deklarasi tes sehingga Anda tidak, karena kesalahan, menghapus pernyataan konversi nomor; jadi cukup tambahkan "tambah dan ubah angka" ke deklarasi it untuk tes ini atau pisahkan menjadi blok baru it. Ini benar-benar tergantung apakah Anda menganggap ini "perilaku standar yang jelas" atau fitur terpisah.

First Pass

Sekarang seperti saya telah mencoba untuk menekankan seluruh artikel ini, ketika Anda melihat spesifikasi yang lewat, saatnya untuk menulis lebih banyak tes. Hal berikutnya yang ingin saya tambahkan adalah array default, jadi di dalam file tagsSpec, mari tambahkan blok it tepat setelah yang sebelumnya:

Di sini kita menggunakan tes baru, persamaan dalam yang bagus untuk mencocokkan dua objek dengan nilai yang sama. Sebagai alternatif, Anda dapat menggunakan tes eql yang merupakan jalan pintas, tetapi saya pikir ini lebih jelas. Tes ini melewati dua argumen sebagai string perintah dan melewati dua default dengan satu tumpang tindih, supaya kita bisa mendapatkan spread yang baik pada kasus uji.

Menjalankan Mocha sekarang, Anda harus mendapatkan semacam diff, yang berisi perbedaan antara apa yang diharapkan dan apa yang sebenarnya ada.

Defaults Diff

Sekarang mari kita kembali ke modul tags.js, dan mari kita tambahkan fungsi ini. Ini adalah perbaikan yang cukup sederhana untuk ditambahkan, kita hanya perlu menerima parameter kedua, dan ketika itu diatur ke objek kita dapat mengganti objek kosong standar di awal dengan objek ini:

Ini akan membawa kita kembali ke keadaan hijau. Hal berikutnya yang ingin saya tambahkan adalah kemampuan untuk hanya menentukan tag tanpa nilai dan biarkan bekerja seperti boolean. Misalnya, jika kami hanya menetapkan --searchContents atau sesuatu seperti itu, itu hanya akan menambahkan itu ke array pilihan kami dengan nilai true.

Tes untuk ini akan terlihat seperti berikut:

Menjalankan ini akan memberi kita kesalahan berikut seperti sebelumnya:

Boolean Tags

Di dalam for loop, ketika kami mendapat kecocokan untuk tag panjang terbentuk, kami memeriksa apakah ada tanda yang sama; kita dapat dengan cepat menulis kode untuk pengujian ini dengan menambahkan klausa else pada pernyataan if itu dan hanya menyetel nilai ke true:

Hal berikutnya yang ingin saya tambahkan adalah substitusi untuk label pendek. Ini akan menjadi parameter ketiga untuk fungsi parse dan pada dasarnya akan menjadi objek dengan huruf dan penggantinya yang sesuai. Berikut adalah spesifikasi untuk tambahan ini:

Masalah dengan tag singkatan adalah bahwa mereka dapat digabungkan secara berurutan. Yang saya maksud dengan ini tidak seperti tag panjang yang terbentuk di mana masing-masing terpisah, dengan tag tangan pendek - karena mereka masing-masing hanya huruf yang panjang - Anda dapat memanggil tiga yang berbeda dengan mengetik -vgh. Ini membuat penguraian sedikit lebih sulit karena kami masih perlu mengizinkan operator yang sama bagi Anda untuk menambahkan nilai ke tag terakhir yang disebutkan, sementara pada saat yang sama Anda masih perlu mendaftarkan tag lainnya. Tapi tidak perlu khawatir, tidak ada yang tidak bisa diselesaikan dengan cukup popping dan bergeser.

Berikut ini seluruh perbaikan, dari awal fungsi parse:

Ada banyak kode (dalam perbandingan) tetapi yang kita lakukan hanyalah membagi argumen dengan tanda yang sama, kemudian membelah kunci itu menjadi huruf-huruf tersendiri. Jadi misalnya jika kita lulus -gj=asd kita akan membagi asd menjadi variabel yang disebut value, dan kemudian kita akan membagi bagian gj menjadi karakter individu. Karakter terakhir (j dalam contoh kita) akan menjadi kunci untuk nilai (asd) sedangkan huruf lain sebelumnya, hanya akan ditambahkan sebagai tag boolean biasa. Saya tidak ingin hanya memproses tag ini sekarang, kalau-kalau kami mengubah implementasinya nanti. Jadi apa yang kami lakukan hanyalah mengubah tag tangan pendek ini menjadi versi yang panjang dan kemudian membiarkan skrip kami menanganinya nanti.

Menjalankan Mocha sekali lagi akan membawa kita kembali ke hasil hijau termasyhur dari empat tes yang lolos untuk modul ini.

Sekarang ada beberapa hal lagi yang dapat kita tambahkan ke modul tag ini untuk membuatnya lebih dekat ke paket npm, seperti kemampuan untuk juga menyimpan argumen teks biasa untuk hal-hal seperti perintah atau kemampuan untuk mengumpulkan semua teks di bagian akhir, untuk properti kueri. Tapi artikel ini sudah lama dan saya ingin melanjutkan untuk mengimplementasikan fungsi pencarian.


Modul Pencarian

Kami baru saja membuat modul langkah demi langkah mengikuti pendekatan TDD dan saya harap Anda mendapatkan ide dan perasaan tentang bagaimana menulis seperti ini. Namun demi menjaga artikel ini terus bergerak, selama sisa artikel, saya akan mempercepat proses pengujian dengan mengelompokkan berbagai hal bersama-sama dan hanya menunjukkan kepada Anda versi terakhir dari pengujian. Ini lebih dari panduan untuk situasi yang berbeda yang mungkin muncul dan bagaimana menulis tes untuk mereka.

Jadi, cukup buat file bernama search.js di dalam folder lib dan file searchSpec.js di dalam folder pengujian.

Selanjutnya buka file spesifikasi dan mari kita setup tes pertama kami yang dapat berfungsi untuk mendapatkan daftar file berdasarkan parameter depth, ini juga merupakan contoh yang bagus untuk tes yang memerlukan sedikit pengaturan eksternal untuk mereka untuk bekerja. Ketika berhadapan dengan objek-seperti-data luar atau dalam file kasus kami, Anda akan ingin memiliki pengaturan standar yang Anda tahu akan bekerja dengan tes Anda, tetapi Anda juga tidak ingin menambahkan informasi palsu ke sistem Anda.

Pada dasarnya ada dua opsi untuk menyelesaikan masalah ini, Anda dapat mencemooh data, seperti yang saya sebutkan di atas jika Anda berurusan dengan perintah bahasa sendiri untuk memuat data, Anda tidak perlu mengujinya. Dalam kasus seperti itu, Anda cukup memberikan data 'diambil' dan melanjutkan dengan pengujian Anda, seperti apa yang kami lakukan dengan string perintah di pustaka tag. Namun dalam kasus ini, kami menguji fungsi rekursif yang kami tambahkan ke kemampuan membaca file bahasa, tergantung pada kedalaman yang ditentukan. Dalam kasus seperti ini, Anda perlu menulis tes dan karena itu kami perlu membuat beberapa file demo untuk menguji pembacaan file. Alternatifnya adalah mungkin untuk menggagalkan fungsi fs untuk hanya menjalankan tetapi tidak melakukan apa-apa, dan kemudian kita dapat menghitung berapa kali fungsi palsu kita berlari atau sesuatu seperti itu (periksa spies) tetapi untuk contoh kita, saya hanya akan membuat beberapa file.

Mocha menyediakan fungsi yang dapat dijalankan sebelum dan sesudah tes Anda, sehingga Anda dapat melakukan pengaturan dan pembersihan eksternal semacam ini di sekitar pengujian Anda.

Untuk contoh kami, kami akan membuat beberapa file dan folder pengujian di dua kedalaman yang berbeda sehingga kami dapat menguji fungsi itu:

Ini akan disebut berdasarkan pada blok describe, dan Anda bahkan dapat menjalankan kode sebelum dan setelah blok it menggunakan beforeEach atau afterEach. Fungsi itu sendiri hanya menggunakan perintah node standar untuk membuat dan menghapus file masing-masing. Selanjutnya kita perlu menulis tes yang sebenarnya. Ini harus tepat di samping fungsi after, masih di dalam blok describe:

Ini adalah contoh pertama kami menguji fungsi async, tetapi karena Anda dapat melihat itu sesederhana sebelumnya; yang perlu kita lakukan adalah menggunakan fungsi done yang disediakan Mocha dalam deklarasi it untuk memberitahukannya ketika kita selesai dengan tes ini.

Mocha akan secara otomatis mendeteksi jika Anda menentukan variabel done dalam callback dan akan menunggu untuk dipanggil sehingga Anda dapat menguji kode asinkron dengan sangat mudah. Juga, perlu disebutkan bahwa pola ini tersedia di seluruh Mocha, Anda dapat misalnya, gunakan ini di before atau sesudah fungsi jika Anda perlu menata sesuatu secara asynchronous.

Berikutnya saya ingin menulis tes yang memastikan parameter kedalaman berfungsi jika diatur:

Tidak ada yang berbeda di sini, hanya tes biasa. Menjalankan ini di Mocha Anda akan mendapatkan kesalahan bahwa pencarian tidak memiliki metode apa pun, pada dasarnya karena kami belum menulis apa pun di dalamnya. Jadi mari kita tambahkan garis besar dengan fungsi:

Jika Anda sekarang menjalankan Mocha lagi, itu akan berhenti menunggu fungsi async ini untuk kembali, tetapi karena kami belum memanggil callback sama sekali, pengujian hanya akan kehabisan waktu. Secara default, waktunya akan habis setelah sekitar dua detik, tetapi Anda dapat menyesuaikan ini menggunakan this.timeout(milliseconds) dalam mendeskripsikan atau memblokir, untuk menyesuaikan waktu habis masing-masing.

Fungsi pemindaian ini seharusnya mengambil jalur dan kedalaman, dan mengembalikan daftar semua file yang ditemukannya. Ini sebenarnya agak sulit ketika Anda mulai berpikir tentang bagaimana kita pada dasarnya mengulang dua fungsi yang berbeda bersama dalam satu fungsi. Kita perlu mengulang melalui folder yang berbeda dan kemudian folder tersebut perlu memindai diri mereka sendiri dan memutuskan untuk melangkah lebih jauh.

Melakukan hal ini secara bersamaan baik-baik saja karena Anda dapat melewatinya satu demi satu, perlahan-lahan menyelesaikan satu level atau jalur pada satu waktu. Ketika berhadapan dengan versi async, ini akan sedikit lebih rumit karena Anda tidak bisa melakukan loop foreach atau sesuatu, karena tidak akan berhenti di antara folder, semuanya pada dasarnya akan berjalan pada waktu yang sama, masing-masing mengembalikan nilai yang berbeda dan mereka akan semacam menimpa satu sama lain.

Jadi untuk membuatnya bekerja, Anda perlu membuat semacam tumpukan di mana Anda dapat memproses satu per satu secara bersamaan (atau sekaligus jika Anda menggunakan antrean) dan kemudian menyimpan beberapa urutan dengan cara itu. Ini adalah algoritma yang sangat spesifik jadi saya hanya menyimpan potongan oleh Christopher Jeffrey yang dapat Anda temukan di Stack Overflow. Ini tidak hanya berlaku untuk memuat file, tetapi saya telah menggunakan ini dalam sejumlah aplikasi, pada dasarnya apa pun di mana Anda perlu memproses suatu array objek satu per satu menggunakan fungsi async.

Kami perlu mengubahnya sedikit, karena kami ingin memiliki opsi kedalaman, bagaimana cara kerja opsi kedalaman adalah Anda mengatur berapa banyak tingkat folder yang ingin Anda periksa, atau nol untuk berulang tanpa batas.

Berikut adalah fungsi yang sudah selesai menggunakan cuplikan:

Mocha sekarang harus melewati kedua tes. Fungsi terakhir yang perlu kita terapkan adalah yang akan menerima larik jalur dan kata kunci pencarian dan mengembalikan semua kecocokan. Ini tes untuknya:

Dan last but not least, mari tambahkan fungsi ke search.js:

Hanya untuk memastikan, jalankan Mocha lagi, Anda harus memiliki total tujuh tes semua berlalu.

All Green

Puting It All Together

Langkah terakhir adalah benar-benar menulis kode lem yang menarik semua modul kita bersama-sama; jadi di akar proyek kami tambahkan file bernama app.js atau sesuatu seperti itu dan tambahkan yang berikut di dalam:

Tidak ada logika yang sebenarnya terjadi di sini, pada dasarnya kami hanya menghubungkan berbagai modul bersama untuk mendapatkan hasil yang diinginkan. Saya biasanya tidak menguji kode ini karena ini hanya kode lem yang semuanya sudah teruji.

Anda sekarang dapat membuat skrip Anda dapat dieksekusi (chmod + x app.js pada sistem Unix) dan kemudian jalankan seperti ini:

Opsional menyesuaikan beberapa placeholder lain yang kami siapkan.

Action Still

Kesimpulan

Dalam artikel ini kami telah membangun aplikasi pencarian file secara keseluruhan, meskipun yang sederhana, tapi saya pikir itu menunjukkan proses secara keseluruhan cukup baik.

Beberapa saran pribadi bergerak maju; jika Anda akan melakukan banyak TDD, atur lingkungan Anda. Banyak waktu overhead yang dikaitkan dengan TDD adalah karena mereka harus terus berpindah jendela, membuka dan menutup file yang berbeda, kemudian menjalankan tes dan mengulang 80 lusin kali sehari. Dalam kasus seperti itu mengganggu alur kerja Anda menurunkan produktivitas. Tetapi jika Anda memiliki pengaturan editor, seperti Anda memiliki tes dan kode sisi-by-side atau IDE Anda mendukung melompat bolak-balik, ini menghemat banyak waktu. Anda juga bisa mendapatkan tes Anda untuk dijalankan secara otomatis dengan memanggilnya dengan tag -w untuk melihat file untuk perubahan dan menjalankan semua tes secara otomatis. Hal-hal semacam ini membuat prosesnya lebih mulus dan lebih banyak bantuan kemudian mengganggu.

Saya harap Anda menikmati artikel ini, jika Anda memiliki pertanyaan, Anda dapat meninggalkannya di bawah ini, hubungi saya di Twitter @gabrielmanricks atau di saluran Nettuts+ IRC (#nettuts di freenode).

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.