Permohonan Ujian Unit Backbone.js

Selepas menghabiskan berjam -jam, mungkin

hari , meletakkan sentuhan penamat pada ciri baru yang hebat untuk aplikasi web anda, anda akhirnya bersedia untuk melihatnya dalam tindakan. Anda menambah kod baru ke pangkalan JavaScript anda, membina calon pelepasan, dan api penyemak imbas anda, mengharapkan kagum. Kemudian ... uh oh ... ciri baru mungkin berfungsi dengan baik, tetapi beberapa bahagian kritikal lain dari aplikasi anda - bahagian yang anda tidak sentuh semasa membangunkan versi baru - telah menjadi sangat teruk. Sekarang anda berhadapan dengan cabaran mundur melalui hari kerja untuk mencuba dan mengetahui bagaimana anda memecahkan kod yang sedia ada. Hari gembira pasti tidak di sini lagi.

senario yang sangat menggigit saya lebih daripada yang saya ingin mengakui. Dan jika anda telah pengekodan seketika, anda mungkin melihatnya juga. Pertimbangkan, bagaimanapun, apa yang membuat senario ini sangat menyakitkan. Ia tidak semestinya kerana kod baru kami memecahkan kod sedia ada; Itu tidak dapat dielakkan dalam pembangunan. Kesakitan sebenar adalah bahawa ia mengambil masa yang lama untuk melihat kerosakan. Dengan begitu banyak perkembangan sejak kami tahu permohonan kami berfungsi, terdapat banyak kod di mana pepijat mungkin bersembunyi. Dan, walaupun ia kelihatan seperti memburu jarum dalam jerami, kita tidak mempunyai pilihan selain menyelamnya.

Dalam artikel ini kita benar -benar akan menghilangkan senario ini dari pembangunan JavaScript kami. Tidak lagi menggali jam, hari, atau minggu kod mencari jarum. Prinsip yang kami pakai adalah mudah: Cari mana -mana bug

sebaik sahaja kami menciptanya. Betul; Kami akan menubuhkan persekitaran pembangunan dan proses yang memberitahu kami dengan segera apabila kami menulis kod yang memperkenalkan bug. Selain itu, usaha tambahan yang kami masukkan ke dalam proses tidak akan membazir sebaik sahaja pembangunan awal selesai. Kod ujian yang sama yang menangkap pepijat pembangunan kami akan diguna semula sepenuhnya dalam persekitaran integrasi. Kami dengan mudah boleh memasukkan ujian ke dalam sistem pengurusan kod sumber kami, menyekat pepijat sebelum mereka dapat masuk ke dalam pangkalan kod kami.

Dalam empat bahagian yang berikut, kita akan melihat alat -alat yang kita perlukan untuk persekitaran ujian JavaScript. Kami kemudian akan mempertimbangkan aplikasi remeh, yang cukup mudah untuk difahami, namun mempunyai semua ciri dan fungsi yang mungkin wujud dalam aplikasi web pengeluaran sebenar. Dua bahagian terakhir menunjukkan bagaimana kita boleh menggunakan persekitaran kita untuk menguji aplikasi contoh semasa pembangunan dan, apabila pembangunan awal selesai, semasa integrasi.

Takeaways Key

• Menekankan pengesanan pepijat awal semasa pembangunan untuk mencegah isu -isu kompleks pada peringkat kemudian, memastikan pengalaman pengekodan yang lancar dan meminimumkan backtracking.
• Gunakan mocha sebagai rangka kerja ujian teras kerana keserasiannya dengan persekitaran penyemak imbas dan node.js, yang membolehkan peralihan lancar dari pembangunan ke ujian integrasi.
menggabungkan perpustakaan penegasan chai untuk meningkatkan kebolehbacaan dan fleksibiliti ujian, menawarkan pelbagai gaya (menegaskan, mengharapkan, harus) yang memenuhi keutamaan pemaju yang berbeza.
menggunakan sinon.js untuk mencipta mata -mata, stub, dan mengejek, yang penting untuk menguji interaksi dengan perpustakaan dan perkhidmatan luaran tanpa menjejaskan operasi mereka.
Sediakan persekitaran ujian yang berterusan menggunakan Test'em untuk menjalankan ujian secara automatik apabila perubahan kod, memberikan maklum balas segera mengenai kesihatan aplikasi.
Semasa pembangunan, fokus pada mewujudkan ujian unit terperinci untuk model, pandangan, dan koleksi untuk memastikan setiap komponen berfungsi dengan betul secara berasingan.
Peralihan dengan lancar ke ujian integrasi dengan menyesuaikan ujian unit untuk pelaksanaan baris arahan dengan node.js, memastikan aplikasi berkelakuan seperti yang diharapkan dalam persekitaran pengeluaran.
memasang persekitaran ujian JavaScript

ujian unit kami Nirvana memerlukan beberapa alat pembangunan yang mungkin tidak berada di meja kerja anda (belum). Berita, baik dan buruk, adalah terdapat banyak pilihan. Itulah berita baik kerana ia memberi kita pilihan, dan itu berita buruk kerana kadar perkembangan akhir depan hari ini bermakna terdapat terlalu banyak pilihan. Untuk memfokuskan penilaian kami, mari kita jelas mengenai dua gol teratas kami. Semua yang lain adalah sekunder:

1. Persekitaran kita mesti menyokong ujian geseran, berterusan semasa pembangunan.
2. ujian yang dibuat semasa pembangunan mesti sama -sama boleh digunakan dalam integrasi.

Persekitaran Pelaksanaan

Untuk pengekodan JavaScript, tidak ada persekitaran pembangunan yang lebih baik daripada pelayar web moden. Sama ada citarasa anda adalah alat pemaju Firebug atau WebKit, penyemak imbas menyokong pemeriksaan dan penyuntingan dom langsung, debugging interaktif penuh, dan analisis prestasi yang canggih. Penyemak imbas web sangat bagus untuk pembangunan, dan alat ujian dan persekitaran kami mesti diintegrasikan dengan pembangunan dalam penyemak imbas. Pelayar web, bagaimanapun, tidak begitu hebat untuk ujian integrasi. Ujian integrasi sering mengambil tempat di pelayan di suatu tempat di awan (atau paling tidak di suatu tempat di pusat data). Sistem tersebut tidak mempunyai antara muka pengguna grafik, apalagi penyemak imbas web moden. Untuk ujian integrasi yang cekap, kami memerlukan skrip baris arahan mudah dan persekitaran pelaksanaan JavaScript yang menyokong mereka. Bagi keperluan tersebut, alat pilihan adalah node.js. Walaupun terdapat persekitaran perintah javascript lain, tidak ada yang mempunyai keluasan dan kedalaman sokongan untuk memadankan Node.js. Dalam fasa integrasi, alat ujian kami mesti diintegrasikan dengan node.js.

Rangka Ujian

Sekarang bahawa kami telah menetapkan bahawa alat ujian kami mesti menyokong kedua -dua penyemak imbas web dan persekitaran Node.js, kami dapat mempersempit pilihan yang cukup untuk memilih rangka kerja ujian teras. Ramai kerangka ujian JavaScript wujud, tetapi kebanyakannya sangat berat sebelah terhadap ujian penyemak imbas; Mendapatkan mereka bekerja dengan node.js biasanya mungkin, tetapi sering memerlukan hacks atau tweak yang tidak masuk akal. Satu rangka kerja yang tidak menderita masalah ini adalah mocha, yang sememangnya menggambarkan dirinya sebagai:

Mocha adalah kerangka ujian JavaScript yang kaya dengan ciri yang berjalan pada nod dan penyemak imbas, membuat ujian tak segerak mudah dan menyeronokkan.

Asalnya dibangunkan untuk node.js, mocha telah diperluaskan untuk menyokong penyemak imbas web dengan mudah. Dengan menggunakan Mocha sebagai rangka kerja ujian kami, kami boleh menulis ujian yang menyokong kedua -dua pembangunan dan integrasi tanpa pengubahsuaian.

Perpustakaan Pernyataan

Tidak seperti beberapa kerangka ujian JavaScript, Mocha direka untuk fleksibiliti maksimum. Akibatnya, kita perlu memilih beberapa bahagian tambahan untuk menjadikannya lengkap. Khususnya, kita memerlukan perpustakaan penegasan JavaScript. Untuk itu, kami akan bergantung kepada Perpustakaan Penegasan Chai. Chai agak unik kerana ia menyokong semua gaya penegasan biasa - menegaskan , mengharapkan, dan harus. kod. Di bawah penutup, mereka semua bersamaan; Sangat mudah untuk menterjemahkan ujian dari satu gaya penegasan ke yang lain. Perbezaan utama dalam gaya pernyataan adalah kebolehbacaan mereka. Pilihan gaya penegasan bergantung pada gaya yang anda (atau pasukan anda) mencari yang paling mudah dibaca, dan gaya mana yang menghasilkan ujian yang paling difahami. Untuk melihat perbezaannya, pertimbangkan untuk membangunkan ujian remeh untuk kod berikut:

<span>var sum = 2 + 2;</span>

Ujian gaya tradisional dan menegaskan boleh ditulis sebagai:

assert<span>.equal(sum, 4, "sum should equal 4");</span>

ujian itu mendapat pekerjaan yang dilakukan, tetapi melainkan jika anda telah terbiasa dengan ujian unit sekolah lama, mungkin sedikit mencabar untuk membaca dan mentafsir. Gaya penegasan alternatif menggunakan jangkaan:

<span>expect(sum).to.equal(4);</span>

Kebanyakan pemaju mencari pernyataan gaya yang lebih mudah untuk dibaca dan difahami daripada ujian gaya menegaskan. Alternatif ketiga, harus membuat pernyataan ujian lebih seperti bahasa semulajadi:

sum<span>.should.equal(4);</span>

Perpustakaan Chai menyokong ketiga -tiga gaya pernyataan. Dalam artikel ini kita akan berpegang teguh.

Spies, Stubs, and Mocks

Kebanyakan aplikasi web, termasuk contoh remeh yang akan kami pertimbangkan dalam artikel ini, bergantung kepada perpustakaan dan perkhidmatan pihak ketiga. Dalam banyak kes, menguji kod kami akan memerlukan pemerhatian - atau mengawal - perpustakaan dan perkhidmatan. Perpustakaan Sinon.js menyediakan banyak alat untuk menguji interaksi tersebut. Alat sedemikian jatuh ke dalam tiga kelas umum:

• Spy . Kod ujian yang memerhatikan panggilan ke fungsi di luar kod yang diuji. Mata -mata tidak mengganggu operasi fungsi luaran; Mereka hanya merekodkan penyerahan dan nilai pulangan.
• Stub . Kod ujian yang bermaksud untuk panggilan ke fungsi di luar kod yang diuji. Kod stub tidak cuba meniru fungsi luaran; Ia hanya menghalang kesilapan yang tidak dapat diselesaikan apabila kod di bawah ujian mengakses fungsi luaran.
• Mock . Kod ujian yang meniru fungsi atau perkhidmatan di luar kod yang diuji. Dengan mengejek, kod ujian boleh menentukan nilai pulangan dari fungsi atau perkhidmatan tersebut supaya dapat mengesahkan respons kod.

Bersama dengan perpustakaan Sinon.js itu sendiri, kita dapat menambah perpustakaan pernyataan chai standard dengan pernyataan sinon.js untuk chai.

Persekitaran Pembangunan Ujian Unit

Alat akhir untuk meja kerja ujian kami adalah persekitaran pembangunan untuk ujian unit. Untuk contoh kami, kami akan menggunakan Test'em. Test'em adalah koleksi skrip berguna untuk menubuhkan dan menjalankan persekitaran ujian yang berterusan. Kita boleh, jika kita memilih, menulis skrip sendiri dan menguruskan alam sekitar secara manual; Walau bagaimanapun, Toby Ho (Pencipta Test'em) telah mengumpulkan pakej hebat yang dapat menyelamatkan kita masalah.

Aplikasi Contoh

Untuk melihat persekitaran ujian kami dalam tindakan, mari kita pertimbangkan aplikasi mudah. Walaupun pared ke keperluan pentingnya, aplikasi ini merangkumi semua fungsi yang diperlukan untuk aplikasi sebenar. (Kod sumber lengkap untuk aplikasi boleh didapati di GitHub.)

Pengguna dapat melihat senarai todos mereka, dan mereka boleh mengklik pada kotak semak untuk bertukar -tukar status Todo.

pangkalan data TODOS

Aplikasi kami bermula dengan jadual pangkalan data yang memegang maklumat untuk TODOS. Inilah SQL yang boleh kita gunakan untuk membuat jadual itu.

<span>var sum = 2 + 2;</span>

Dan inilah caranya jadual mungkin kami telah meletakkan beberapa data ujian di dalamnya.

id tajuk Lengkap 1A sampel item todo dalam pangkalan data0 Sampel 2 orang item TODO1 3yet contoh todo sampel yang lain

seperti yang ditunjukkan oleh jadual, todos kami hanya termasuk kunci utama (ID), tajuk, dan sedikit status untuk menunjukkan sama ada atau tidak mereka selesai.

API REST

Aplikasi web kami memerlukan akses ke pangkalan data ini, jadi kami akan menyediakan antara muka REST standard. API mengikuti konvensyen Ruby, tetapi boleh dilaksanakan dengan mudah oleh mana -mana teknologi pelayan. Khususnya:

Dapatkan API/TODOS Mengembalikan pelbagai baris yang dikodkan oleh JSON dalam pangkalan data.
Dapatkan API/TODOS/NNN Mengembalikan perwakilan JSON TODO dengan ID sama dengan NNN.
Post API/Todos menambah todo baru ke pangkalan data menggunakan maklumat yang dikodkan JSON dalam permintaan.
Letakkan API/TODOS/NNN mengemas kini TODO dengan ID sama dengan NNN menggunakan maklumat yang dikodkan JSON dalam permintaan.
Padam API/TODOS/NNN Memadamkan TODO dengan ID sama dengan NNN dari pangkalan data.

Jika anda tidak suka Ruby, kod sumber termasuk pelaksanaan PHP lengkap API ini.

perpustakaan JavaScript

Aplikasi sederhana kami cukup mudah untuk dilaksanakan di JavaScript tulen tanpa sebarang perpustakaan, tetapi kami mempunyai rancangan yang jauh lebih besar. Kami mungkin bermula kecil, tetapi akhirnya aplikasi akan menampilkan fungsi yang menakjubkan dan antara muka pengguna yang menarik. Sebagai persediaan untuk hari itu, kami akan membina rangka kerja yang dapat menyokong aplikasi pembunuh utama kami:

• jQuery untuk manipulasi DOM, pengendalian acara, dan komunikasi pelayan.
• underscore.js untuk meningkatkan bahasa teras dengan banyak utiliti yang tidak dapat dijangkiti.
• backbone.js untuk menentukan struktur aplikasi dari segi model dan pandangan.

Skeleton HTML

Sekarang kita tahu komponen yang akan terdiri daripada aplikasi kita, kita boleh menentukan rangka HTML yang akan menyokongnya. Tidak ada apa -apa yang mewah mengenainya (namun), hanya dokumen HTML5 yang minimum, beberapa fail JavaScript, dan sedikit kod untuk memulakan sesuatu.

<span>var sum = 2 + 2;</span>

ujian semasa pembangunan

Sekarang kami telah memilih alat kami dan menetapkan aplikasi, sudah tiba masanya untuk memulakan pembangunan. Tugas pertama kami sedang memasang alat.

Memasang alat

Walaupun kami akan membangun dalam penyemak imbas, persekitaran ujian kami bergantung pada Node.js. Oleh itu, langkah pertama adalah memasang Node.js dan Pengurus Pakej Node (NPM). Terdapat binari yang boleh dilaksanakan untuk OS X, Windows, Linux, dan Sunos di laman web Node.js, serta kod sumber untuk sistem operasi lain. Selepas menjalankan pemasang, anda boleh mengesahkan kedua -dua node.js dan npm dari baris arahan.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

segala -galanya yang kita perlukan boleh didapati dengan mudah sebagai pakej nod. Pengurus Pakej Node boleh mengendalikan pemasangan mereka, serta sebarang kebergantungan.

<span>expect(sum).to.equal(4);</span>

Membuat struktur projek

Kod sumber untuk contoh ini termasuk struktur projek lengkap dengan 15 fail berikut:

sum<span>.should.equal(4);</span>

inilah yang setiap folder dan fail mengandungi:

• todos.html: Fail HTML Skeleton untuk aplikasi kami, ditunjukkan sepenuhnya di atas.
• testem.json: Fail konfigurasi untuk test'em; Kami akan melihat ini secara terperinci tidak lama lagi.
• API/: Folder untuk pelaksanaan API REST kami.
  • API/HTACCESS: Konfigurasi sampel untuk pelayan web Apache yang menyokong API REST kami.
  • API/Todos.php: Kod PHP untuk melaksanakan API REST.
• lib/: folder untuk perpustakaan JavaScript yang digunakan oleh aplikasi itu sendiri dan kerangka ujian.
  • lib/backbone-min.js: versi minified backbone.js.
  • lib/chai.js: Perpustakaan penegasan chai.
  • lib/jQuery-1.9.0.min.js: Versi minified jQuery.
  • lib/sinon-1.5.2.js: Perpustakaan Sinon.js.
  • lib/sinon-chai.js: pernyataan sinon.js untuk chai.
  • lib/garis bawah-min.js: Versi minified underscore.js.
• mysql/: folder untuk kod MySQL untuk permohonan itu.
  • mysql/todos.sql: perintah mysql untuk membuat pangkalan data aplikasi.
• php-lib/: folder untuk perpustakaan PHP dan konfigurasi untuk API REST aplikasi.
  • php-lib/dbconfig.inc.php: Konfigurasi pangkalan data PHP untuk API REST.
• src/: folder untuk kod aplikasi sisi klien kami.
  • src/app-todos.js: aplikasi kami.
• ujian/: folder untuk kod ujian.
  • ujian/app-todos-test.js: kod ujian untuk aplikasi kami.
  • test/mocha.opts: pilihan konfigurasi untuk mocha; Kami akan melihat ini di bahagian seterusnya.

Semasa pembangunan, kami hanya berminat dengan tiga fail ini, testem.json, src/app-todos.js, dan ujian/app-todos-test.js.

Mengkonfigurasi Test'em

Langkah terakhir sebelum pembangunan sebenar menentukan konfigurasi Test'em. Konfigurasi itu berada dalam testem.json yang diformat JSON, dan ia cukup mudah untuk dibuat dalam mana-mana editor teks. Kami hanya menyatakan bahawa kami menggunakan mocha (test'em menyokong beberapa rangka kerja), dan kami menyenaraikan fail JavaScript permohonan kami dan kod ujian kami memerlukan.

<span>var sum = 2 + 2;</span>

mula membangunkan

Akhirnya, kami sudah bersedia untuk kod. Dalam shell arahan, navigasi ke folder root projek kami dan laksanakan testem perintah. Skrip ujian akan berjalan, membersihkan tetingkap terminal dan memberi kita URL di sebelah kanan atas. Salin dan tampal URL ke dalam penyemak imbas pilihan kami dan kami pergi.

Sebaik sahaja kami melancarkan pelayar web, ia secara automatik akan melaksanakan sebarang ujian yang telah kami tentukan. Oleh kerana kita baru memulakan pembangunan, kita tidak akan mempunyai sebarang kod, atau sebarang kes ujian. Penyemak imbas akan menunjuk kepada kami.

Tetingkap terminal dari mana kami melancarkan Test'em juga akan memberi kami status.

kes ujian pertama

Dalam semangat pembangunan yang didorong oleh ujian yang benar, kami akan bermula dengan menulis kes ujian pertama kami dalam fail ujian/app-todos-test.js. Seperti mana -mana aplikasi web yang baik, kami mahu meminimumkan pencemaran ruang nama global. Untuk melakukan itu, kami akan bergantung kepada pemboleh ubah global tunggal, TodoApp, untuk mengandungi semua kod kami. Kes ujian pertama kami akan memastikan bahawa pembolehubah ruang nama global wujud.

<span>var sum = 2 + 2;</span>

Seperti yang anda lihat, kami memerlukan satu pernyataan awal untuk memberitahu Mocha bahawa kami menggunakan pernyataan chai. Kemudian kita boleh mula menulis ujian. Dengan ujian JavaScript konvensyen dianjurkan ke dalam blok (yang boleh bersarang ke dalam sub-blok, dan sebagainya). Setiap blok bermula dengan panggilan fungsi () untuk mengenal pasti bahagian kod yang kami uji. Dalam kes ini kami sedang menguji aplikasi keseluruhan, jadi itulah parameter pertama untuk menggambarkan ().

Dalam blok ujian, kami mendokumenkan setiap kes ujian dengan apa yang diuji. Itulah tujuan fungsi IT (). Cara untuk membaca mana -mana kes ujian adalah untuk menggabungkan gambaran () dan ia () rentetan ke dalam satu pernyataan. Oleh itu, kes ujian pertama kami ialah

Aplikasi membuat pemboleh ubah global untuk ruang nama

Kod ujian itu sendiri berada di dalam blok IT (). Kes ujian kami ialah

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Sekarang kita mempunyai kes ujian lengkap. Sebaik sahaja kami menyimpan fail, test`em secara automatik mengambil alih. Ia mendapati bahawa salah satu fail kami telah berubah, jadi ia segera mengubah ujian. Tidak menghairankan (kerana kami belum menulis sebarang kod untuk permohonan itu), ujian pertama kami gagal.

kemas kini tetingkap terminal secara automatik juga.

Untuk membuat lulus ujian, kita mesti membuat pemboleh ubah ruang nama global. Kami beralih ke fail srcapp-todos.js dan menambah kod yang diperlukan.

<span>expect(sum).to.equal(4);</span>

sebaik sahaja kami menyimpan fail, test`em sekali lagi muncul untuk bertindak. Kami segera mendapat keputusan yang dikemas kini untuk kes ujian kami.

Langkah mundur seketika dan pertimbangkan apa yang berlaku! Setiap kali kita membuat perubahan, sama ada ke kod ujian atau permohonan kami, Test`em segera menjalankan semula keseluruhan ujian kami. Apa yang perlu kita lakukan ialah menyimpan pelayar Test'em atau tetingkap terminal yang dapat dilihat di sudut skrin kami, dan kami dapat melihat kesihatan kod kami dalam masa nyata, seperti yang kita sedang membangunkan . Kami akan tahu sebaik sahaja kami memperkenalkan pepijat, walaupun bug itu menunjukkan dirinya dalam sebahagian daripada kod yang berbeza dari mana kami bekerja. Tidak lagi menggali kembali melalui jam, hari, atau minggu kod baru untuk mengetahui apabila kami memperkenalkan bug.

Menguji model

Dengan persekitaran pembangunan kami kini ditubuhkan sepenuhnya, kami boleh mula membangunkan aplikasi. Oleh kerana aplikasi kami menunjukkan senarai todos, mungkin baik untuk membuat model untuk todos. Model ini perlu menjejaki kedua -dua tajuk todo dan status itu. Mari tambahkan ujian unit yang mengesahkan kita boleh membuat todo dengan mungkir yang munasabah.

<span>var sum = 2 + 2;</span>

Terdapat beberapa aspek ujian ini yang perlu diperhatikan.

• kita boleh bersarang blok ujian dalam satu sama lain. Satu blok ujian akan mengandungi semua ujian unit untuk model TODO, dan sub-blok ujian tersebut memberi tumpuan kepada permulaan.
• Dalam blok ujian, kita boleh menentukan fungsi untuk dilaksanakan sebelum setiap ujian. Itulah tujuan blok sebelumnya (). Dalam contoh di atas, kami mencipta contoh baru todo sebelum setiap ujian.
• Kerangka Mocha secara automatik memastikan bahawa konteks JavaScript (iaitu nilai ini) adalah konsisten untuk semua kes ujian kami. Itulah sebabnya kita boleh menentukan ini.todo dalam satu fungsi (parameter sebelum ini) dan selamat merujuknya dalam fungsi lain (seperti parameter IT ()). Tanpa Mocha bekerja di belakang tabir untuk memberikan konsistensi ini, JavaScript akan menentukan konteks yang berbeza untuk setiap fungsi.

Sudah tentu, kerana kami belum menulis kod model, semua ujian kami akan gagal. (Dan kita akan tahu dengan serta -merta.) Tetapi apabila kita telah menambah kod untuk model kami, ujian lulus dan kami sedang dalam perjalanan.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

menggunakan stub untuk fungsi pihak ketiga

Sekarang kita mempunyai model mudah untuk Todos, kita boleh mula menentukan tingkah lakunya. Satu perkara yang harus dilakukan oleh model kami ialah mengemas kini pangkalan data apabila mana -mana sifatnya berubah. Walau bagaimanapun, dalam persekitaran ujian unit, kami tidak akan mempunyai pangkalan data sebenar untuk diperiksa. Sebaliknya, kami sebenarnya tidak menulis sebarang kod untuk melakukan kemas kini pangkalan data. Sebaliknya, kami bergantung pada tulang belakang untuk mengendalikan interaksi itu. Itu mencadangkan strategi ujian unit untuk kes ujian ini. Apa yang perlu kita ketahui ialah model tulang belakang menggunakan kaedah SAVE () untuk mengemas kini apa sahaja kedai sokongan yang berterusan model. Dalam kes kami, kedai sokongan adalah pangkalan data. Inilah kod ujian unit yang boleh kita gunakan:

<span>expect(sum).to.equal(4);</span>

Kami telah memasukkan beberapa kod tambahan sebelum setiap ujian, dan kami telah menambah seksyen kod untuk dilaksanakan selepas setiap ujian. Kod tambahan itu menguruskan stub sinon, fungsi yang secara berkesan membatalkan fungsi lain dalam kod. Dalam kes kami, stub membatalkan kaedah simpanan () ini.todo ini. Dengan stub di tempat, panggilan ke kaedah tidak akan pergi ke perpustakaan belakang. Sebaliknya, Sinon memintas panggilan tersebut dan hanya kembali dengan segera. Tingkah laku ini penting. Jika kami cuba melaksanakan kaedah Backbone Save () sebenar dalam persekitaran ujian unit, panggilan akan gagal kerana tidak akan ada pangkalan data atau API pelayan yang tersedia.

Dengan stub di tempat, kes ujian kami boleh menggunakannya untuk mengesahkan tingkah laku model. Dalam kes ujian pertama, kami segera menetapkan tajuk Todo kepada nilai baru. Oleh kerana itu mengubah harta tajuk, kami mahu model kami mengemas kini kedai sokongannya. Untuk memeriksa bahawa kami hanya mengesahkan bahawa stub dipanggil. Untuk mendapatkan model kami untuk lulus ujian ini, kami boleh mencari peristiwa perubahan dan bertindak balas dengan sewajarnya.

<span>var sum = 2 + 2;</span>

Menguji pandangan

Sudah tentu, aplikasi kami tidak akan melakukan apa -apa yang baik jika ia tidak benar -benar memaparkan todos kepada pengguna, dan itu memerlukan membuat beberapa HTML. Kami akan menggunakan pandangan tulang belakang untuk fungsi itu. Dalam aplikasi remeh kami, kami hanya ingin menjadikan setiap todo sebagai item senarai. Berikut adalah kes ujian yang akan memulakan kita.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Kami memulakan ujian pandangan kami dengan dua kes ujian. Mula -mula kita memastikan bahawa kaedah render () paparan mengembalikan pandangan itu sendiri. Itulah konvensyen yang biasa dan sangat mudah di tulang belakang kerana ia membolehkan kaedah chaining. Kes ujian kedua kami mengesahkan bahawa elemen HTML yang dibuat adalah item senarai (

). Kod yang diperlukan untuk lulus ujian ini adalah pandangan tulang belakang yang mudah. ​​

<span>expect(sum).to.equal(4);</span>

Seterusnya, kita boleh membangunkan kandungan terperinci paparan item senarai itu. Sebagai contoh, kami mahu item senarai penuh untuk melihat sesuatu seperti yang berikut.

sum<span>.should.equal(4);</span>

Untuk kes ujian kami, kami boleh mengambil kesempatan daripada jQuery untuk mengekstrak elemen individu dari elemen utama pandangan.

CREATE TABLE `todos` (
  `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
  `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
  `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'

Perhatikan bahawa dalam kes ujian terakhir kami telah meretas kaedah SAVE () model. Oleh kerana kami menukar harta dari nilai lalai, model kami akan dengan penuh semangat cuba untuk meneruskan perubahan ke kedai sokongannya. Walau bagaimanapun, dalam persekitaran ujian unit, kami tidak akan mempunyai pangkalan data atau API pelayan. Stub mengambil tempat komponen yang hilang dan membolehkan ujian diteruskan tanpa kesilapan. Untuk mendapatkan ujian ini, kami perlu menambah beberapa kod tambahan kepada pandangan kami.

<span><span><!DOCTYPE html></span>
</span><span><span><span><html</span> lang<span>="en"</span>></span>
</span>  <span><span><span><head</span>></span>
</span>    <span><span><span><meta</span> charset<span>="utf-8"</span>></span>
</span>    <span><span><span><title</span>></span><span><span></title</span>></span>
</span>  <span><span><span></head</span>></span>
</span>  <span><span><span><body</span>></span>
</span>    <span><span><span><h1</span>></span>List of Todos<span><span></h1</span>></span>
</span>
    <span><span><span><script</span> src<span>="lib/jquery-1.9.0.min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="lib/underscore-min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="lib/backbone-min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="src/app-todos.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span>></span><span>
</span></span><span><span>      <span>$(function () {
</span></span></span><span><span>        <span>var todos = new todoApp<span>.Todos</span>();
</span></span></span><span><span>        todos<span>.fetch();
</span></span></span><span><span>        <span>var list = new todoApp<span>.TodosList</span>({collection: todos});
</span></span></span><span><span>        <span>$("body").append(list.el);
</span></span></span><span><span>      <span>})
</span></span></span><span><span>    </span><span><span></script</span>></span>
</span>  <span><span><span></body</span>></span>
</span><span><span><span></html</span>></span></span>

Model ujian/pandangan interaksi

Sekarang bahawa kami telah mengesahkan bahawa pelaksanaan pandangan kami mencipta markup HTML yang betul, kami dapat menguji interaksi dengan model kami. Khususnya, kami ingin memastikan pengguna boleh menukar status todo dengan mengklik pada kotak semak. Persekitaran ujian kami tidak memerlukan pengguna manusia yang sebenar, jadi kami akan menggunakan jQuery untuk menghasilkan acara klik. Walau bagaimanapun, untuk melakukan itu, kita perlu menambah kandungan ke DOM yang sebenar. Kandungan itu dikenali sebagai ujian perlawanan . Berikut adalah kod ujian unit.

bash-3.2$ node --version
v0.8.18
bash-3.2$ npm --version
1.2.2
bash-3.2$

Perhatikan bahawa kami sekali lagi menetas kaedah SAVE () TODO. Jika tidak, Backbone akan cuba mengemas kini kedai sokongan yang tidak wujud apabila kami menukar status Todo dengan klik simulasi kami.

Untuk kes ujian itu sendiri, kita mulakan dengan membuat elemen

dengan ID perlawanan dan kami menambah elemen itu ke dokumen langsung kami. Dokumen langsung, dalam kes ini, adalah laman web yang memaparkan hasil ujian kami. Walaupun kami mengeluarkan elemen dengan segera selepas mengesahkan kes ujian, kami juga menetapkan harta paparannya kepada tiada sehingga ia tidak akan mengganggu paparan Mocha hasil ujian. Kod yang melaksanakan fungsi ini termasuk tambahan kecil kepada model TODO. Penambahannya adalah kaedah togglestatus baru ().

<span>var sum = 2 + 2;</span>

Dalam paparan, kami ingin menangkap acara klik pada elemen dan panggil kaedah ini untuk model.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Menguji koleksi

Pada masa ini permohonan kami hampir selesai. Satu -satunya fungsi yang tersisa adalah mengumpul semua todos bersama -sama. Sememangnya, kami akan menggunakan koleksi tulang belakang. Kami sebenarnya tidak akan melakukan apa -apa yang istimewa dengan koleksi kami, jadi kami tidak memerlukan sebarang ujian unit.

<span>expect(sum).to.equal(4);</span>

kita boleh mengesahkan bahawa pelaksanaan pandangan koleksi kami adalah sesuai. Kami mahu pandangan yang diberikan sebagai senarai yang tidak teratur (

). Kes ujian tidak memerlukan sebarang fungsi yang belum pernah kita lihat sebelumnya.

sum<span>.should.equal(4);</span>

Pelaksanaan pandangan juga mudah. Ia menjejaki sebarang penambahan ke koleksi dan mengemas kini paparan. Untuk render awal () ia hanya menambah semua model dalam koleksi satu demi satu.

CREATE TABLE `todos` (
  `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
  `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
  `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'

ujian bonus: mengesahkan API

Kerana API REST kami sempurna sepadan dengan API yang diharapkan oleh tulang belakang, kami tidak memerlukan sebarang kod tersuai untuk menguruskan interaksi API. Akibatnya, kami tidak memerlukan sebarang kes ujian unit. Di dunia nyata, anda mungkin tidak begitu bernasib baik. Jika API anda tidak mematuhi konvensyen tulang belakang, anda mungkin perlu menimpa atau melanjutkan beberapa kod tulang belakang untuk menangani API yang tidak standard. Kod tambahan itu memerlukan ujian unit juga. Mujurlah, ia agak mudah untuk menguji interaksi API, walaupun dalam persekitaran ujian unit.

Cara paling mudah untuk menguji interaksi API bergantung pada fungsi pelayan palsu Sinon.js. Malangnya, fungsi itu hanya tersedia (pada masa ini) dalam pelaksanaan pelayar Sinon. Ia secara eksplisit dikecualikan daripada pelaksanaan Node.js. Terdapat beberapa hacks untuk mendapatkannya berjalan di node.js, tetapi hacks itu agak rapuh dan bergantung pada butiran pelaksanaan dalaman. Adalah lebih baik untuk mengelakkan mereka jika boleh. Nasib baik, kita boleh mendapatkan tanpa pelayan palsu Sinon.

Rahsia mengetahui bahawa Backbone bergantung pada fungsi JQuery's $ .ajax () untuk melaksanakan API REST. Kita boleh memintas interaksi API dengan menonjolkan fungsi itu. Apabila kita melengkapkan fungsi, kita akan mahu menggantikan respons kita sendiri. Kaedah hasil () stub memberikan kita peluang itu. Ia memberitahu Sinon apa tindakan tambahan yang perlu diambil apabila stub dipanggil. Berikut adalah kes ujian lengkap untuk mengesahkan bahawa koleksi kami dengan betul memulakan sendiri menggunakan API REST.

<span>var sum = 2 + 2;</span>

selesai!

Seperti yang anda lihat dari pukulan skrin yang berikut, kami kini telah menulis kod yang melepasi semua kes ujian unit. Buat masa ini sekurang -kurangnya, pembangunan selesai.

ujian semasa integrasi

Sekarang perkembangan klien aplikasi kami selesai (dan kami mempunyai ujian untuk membuktikannya), kami dengan selamat boleh memasukkan JavaScript kami ke dalam sistem pengurusan kod sumber. Ia kemudiannya boleh diintegrasikan ke dalam proses membina untuk keseluruhan aplikasi. Sebagai sebahagian daripada proses itu, kami mahu melaksanakan semua kes ujian yang telah kami usahakan. Ini akan memastikan bahawa kod yang membentuk penggunaan akhir melepasi semua ujian yang telah kami tentukan. Ia juga akan melindungi daripada "tweak kecil" kepada kod yang secara tidak sengaja memperkenalkan pepijat baru.

Semasa proses binaan, kami mungkin ingin melaksanakan ujian kami dari baris arahan dan bukannya dalam pelayar web. Kami tidak memerlukan butiran kes ujian individu, hanya jaminan bahawa mereka semua lulus. Node.js menjadikannya cukup mudah untuk menampung keperluan ini. Kami hanya perlu membuat beberapa tambahan kecil ke kod sumber kami dan fail kod ujian unit.

Kod kami memerlukan pengubahsuaian ini kerana Node.js mengendalikan pembolehubah global secara berbeza daripada pelayar web. Dalam pelayar web, pembolehubah JavaScript adalah, secara lalai, global dalam skop. Node.js, sebaliknya, mengurung pembolehubah ke modul tempatan mereka secara lalai. Dalam persekitaran itu, kod kami tidak akan dapat mencari perpustakaan pihak ketiga yang diperlukan (jQuery, underscore, dan tulang belakang. Jika kami menambah pernyataan berikut pada mulanya, node.js akan menyelesaikan rujukan kepada perpustakaan ini dengan sewajarnya . Kami telah membina kenyataan ini supaya mereka tidak membahayakan penyemak imbas web, jadi kami boleh meninggalkannya dalam kod secara kekal.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Kami juga perlu menyesuaikan kod ujian kami. Skrip ujian memerlukan akses ke perpustakaan mereka sendiri (jQuery, chai, sinon.js, dan sinon-chai). Di samping itu, kita perlu menambah sedikit tambahan untuk mensimulasikan model objek dokumen pelayar web (DOM). Ingatlah bahawa ujian kami untuk pengendalian klik memerlukan kami untuk sementara menambah "perlawanan"

ke laman web. Node.js, tentu saja, biasanya tidak mempunyai laman web. Pakej nod JSDOM, bagaimanapun, membolehkan kita mencontohi satu. Kod di bawah mewujudkan laman web yang minimum dan simulasi untuk ujian kami.

<span>var sum = 2 + 2;</span>

Bersyarat yang membungkus ujian pernyataan ini untuk melihat sama ada kita berjalan di persekitaran Node.js dan bukannya pelayar web. Dalam penyemak imbas, pernyataan tambahan tidak diperlukan, jadi kami dapat melangkauinya dengan selamat.

Dengan perubahan itu, kita boleh melaksanakan suite ujian penuh dari baris arahan. Hanya navigasi ke folder root projek dan laksanakan perintah mocha. Hasilnya kelihatan agak biasa.

Sudah tentu, Mocha mengembalikan tahap keluar untuk menunjukkan sama ada atau tidak semua ujian yang diluluskan. Itu membolehkan kita mengautomasikan ujian sebagai sebahagian daripada proses integrasi yang berterusan, atau hanya sebagai skrip pra-komite tempatan untuk memelihara kewarasan kita sendiri.

Kesimpulan

Pada ketika ini kami telah mencapai matlamat kami. Kami mempunyai persekitaran ujian unit yang berjalan di latar belakang semasa pembangunan dan segera memberitahu kami apabila sebarang ujian gagal. Ujian dilaksanakan dalam pelayar web, memberikan kami akses penuh ke alat pembangunan pelayar semasa kami pengekodan. Ujian yang sama juga berjalan dengan baik dari skrip baris arahan, jadi kami boleh mengautomasikan pelaksanaannya semasa proses binaan atau integrasi.

Sumber

Berikut adalah sumber ujian unit utama yang digunakan dalam artikel.

• Lingkungan Perintah JavaScript Alam Sekitar: Node.js
• Rangka Kerja Ujian Unit JavaScript: Mocha
• Persekitaran Pembangunan Ujian: Test'em
• Perpustakaan Penegasan JavaScript: Perpustakaan Dakwaan Chai
• Spies, Stubs, and Mocks: Sinon.js
• Penegasan tambahan: Sinon.js Pernyataan untuk Chai

Soalan Lazim (Soalan Lazim) pada Unit Menguji Backbone.js Aplikasi

Apakah kepentingan ujian unit dalam aplikasi Backbone.js? Ia melibatkan ujian komponen individu perisian untuk memastikan ia berfungsi seperti yang diharapkan. Ini membantu dalam mengenal pasti dan menetapkan pepijat awal dalam proses pembangunan, dengan itu menjimatkan masa dan sumber. Selain itu, ujian unit memudahkan refactoring kod, kerana pemaju boleh membuat perubahan pada kod dan dengan cepat mengesahkan jika perubahan telah memecahkan fungsi sedia ada. Ia juga meningkatkan reka bentuk kod, kerana ujian menulis sering membawa kepada modularization yang lebih baik dan perpaduan tinggi kod.

Bagaimanakah ujian unit dalam tulang belakang.js dibandingkan dengan kerangka JavaScript yang lain? Walau bagaimanapun, Backbone.js menonjol kerana fleksibiliti dan kesederhanaannya. Ia tidak menentukan bagaimana permohonan anda harus berstruktur, memberikan pemaju kebebasan untuk merancang aplikasi mereka seperti yang mereka lihat patut. Fleksibiliti ini meliputi ujian unit, yang membolehkan pemaju memilih alat ujian dan metodologi pilihan mereka. Selain itu, Backbone.js mempunyai jejak yang lebih kecil berbanding dengan kerangka lain, menjadikannya lebih cepat dan lebih efisien untuk ujian unit. adalah beberapa alat yang tersedia untuk ujian unit dalam Backbone.js. Beberapa yang popular termasuk Mocha, Jasmine, dan Jest. Mocha adalah rangka kerja ujian JavaScript yang kaya dengan ciri yang menyediakan pemaju dengan cara mudah untuk menguji aplikasi mereka. Jasmine adalah rangka kerja pembangunan yang didorong oleh tingkah laku untuk menguji kod JavaScript. Ia tidak bergantung kepada pelayar, DOM, atau mana -mana rangka kerja JavaScript, menjadikannya sesuai untuk menguji aplikasi Backbone.js. Jest, sebaliknya, adalah penyelesaian ujian yang komprehensif dengan fokus pada kesederhanaan dan sokongan untuk aplikasi web yang besar. Ujian untuk aplikasi Backbone.js melibatkan membuat kes ujian untuk setiap komponen aplikasi. Ini termasuk model, pandangan, dan koleksi. Setiap kes ujian harus meliputi fungsi khusus komponen dan harus bebas dari kes ujian lain. Anda boleh menggunakan kerangka ujian seperti mocha atau melati untuk menulis ujian anda. Rangka kerja ini menyediakan fungsi untuk menentukan kes ujian, menubuhkan dan meruntuhkan persekitaran ujian, dan membuat pernyataan. JS bergantung kepada kerangka ujian yang anda gunakan. Sebagai contoh, jika anda menggunakan mocha, anda boleh menjalankan ujian anda menggunakan alat baris perintah mocha. Jika anda menggunakan melati, anda boleh menjalankan ujian anda menggunakan alat baris perintah melati. Alat ini menyediakan pilihan untuk menjalankan kes ujian individu, keseluruhan suite ujian, atau semua ujian dalam aplikasi anda. Mereka juga menyediakan laporan terperinci mengenai keputusan ujian, termasuk bilangan ujian yang diluluskan, gagal, dan dilangkau. Automatikkan ujian unit dalam Backbone.js. Automasi melibatkan penyediaan sistem integrasi berterusan (CI) yang secara automatik menjalankan ujian anda apabila perubahan dibuat ke kod. Ini memastikan bahawa sebarang pepijat yang diperkenalkan oleh perubahan itu ditangkap dengan segera. Terdapat beberapa alat CI yang tersedia, seperti Jenkins, Travis CI, dan CircleCi, yang menyokong JavaScript dan boleh digunakan untuk mengautomasikan ujian unit dalam Backbone.js.

Apakah beberapa amalan terbaik untuk ujian unit dalam tulang belakang.js?

Beberapa amalan terbaik untuk ujian unit dalam tulang belakang.js termasuk menulis ujian kecil dan fokus yang meliputi satu fungsi, menjaga ujian bebas antara satu sama lain , dan menguji semua kes kelebihan yang mungkin. Ia juga penting untuk menulis ujian sebelum menulis kod sebenar, amalan yang dikenali sebagai pembangunan yang didorong oleh ujian (TDD). Ini memastikan bahawa kod anda boleh diuji dan membantu anda merancang perisian yang lebih baik.

Bagaimana saya boleh debug ujian unit gagal dalam tulang belakang.js?

Laporan untuk mengenal pasti punca kegagalan. Rangka kerja yang paling banyak memberikan mesej ralat terperinci yang dapat membantu anda menentukan masalah. Anda juga boleh menggunakan alat debugging seperti devtools Chrome atau debugger node.js untuk melangkah melalui kod anda dan memeriksa pembolehubah dan panggilan fungsi.

Bolehkah saya menggunakan mocks dan stubs dalam unit ujian Backbone.js?

Ya, anda boleh menggunakan mocks dan stubs dalam unit ujian Backbone.js. Mocks dan stubs adalah objek palsu yang mensimulasikan tingkah laku objek sebenar. Mereka digunakan untuk mengasingkan komponen yang diuji dari seluruh sistem. Ini menjadikan ujian lebih dipercayai dan mudah ditulis. Terdapat beberapa perpustakaan yang tersedia, seperti sinon.js, yang menyediakan fungsi untuk membuat dan menguruskan mocks dan stubs. Prestasi ujian unit dalam tulang belakang.js melibatkan mengoptimumkan ujian dan persekitaran ujian anda. Ini termasuk menulis ujian yang cekap yang melaksanakan dengan cepat, menjalankan ujian selari, dan menggunakan rangka kerja ujian yang cepat. Anda juga boleh menggunakan alat profil untuk mengenal pasti ujian perlahan dan kesesakan dalam proses ujian anda.

Atas ialah kandungan terperinci Permohonan Ujian Unit Backbone.js. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!