Nodejs nota kajian test drive_node.js

Kongsi bab kedua, tentang pemanduan ujian. Ujian di sini adalah terutamanya untuk ujian back-end Web - mengapa anda perlu menulis kes ujian (iaitu, sama ada menambah baik kes ujian adalah membuang masa), cara menambah baik kes ujian anda, cara reka bentuk kod boleh memudahkan penulisan kes ujian , dan beberapa idea kemudiannya.

1. Mengapa anda perlu menulis kes ujian

Kebiasaan ini biasanya dianggap sebagai tingkah laku yang melambatkan kemajuan pembangunan Anda perlu meluangkan masa yang hampir sama membangunkan kod anda untuk memperbaiki kes ujian anda secara beransur-ansur. Walau bagaimanapun, semasa proses pembangunan, selepas membangunkan sekeping kod, jika anda bertanggungjawab dan tidak menyerahkan masalah kepada penguji untuk mencarinya, anda biasanya akan melakukan beberapa ujian manual pada masa ini. Contohnya:

Laksanakan kaedah tertentu dalam kod untuk melihat sama ada nilai output adalah seperti yang dijangkakan.
Ubah suai pangkalan data/cache, dan kemudian laksanakan kaedah tertentu untuk melihat sama ada perubahan pangkalan data adalah seperti yang diharapkan.
Gunakan alatan untuk mensimulasikan permintaan antara muka tertentu untuk melihat sama ada nilai pulangan antara muka/nilai yang diubah dalam pangkalan data memenuhi jangkaan.
Jika terdapat halaman hadapan, ia juga akan melibatkan penyahpepijatan bersama bahagian hadapan dan belakang, iaitu, melalui interaksi bahagian hadapan pada halaman hujung hadapan, semak sama ada maklum balas bahagian hadapan memenuhi jangkaan untuk mengesahkan secara tidak langsung ketepatan kod hujung belakang.
Alat ujian moden cuba sedaya upaya untuk mengabstrakkan tingkah laku ujian manual ini ke dalam blok kod Apabila anda secara sedar melakukan ujian manual, anda sebenarnya telah mula mencuba kelakuan kes ujian. Memandangkan ujian boleh dilakukan secara manual, mengapa anda perlu menggunakan kod untuk melaksanakan ujian?

Kod boleh digunakan semula atau boleh mencapai lebih banyak fungsi selepas pemfaktoran semula yang mudah, tetapi apabila anda memilih untuk melakukannya secara manual, anda perlu memulakan semula setiap kali.
Aliran kerja matang harus termasuk proses semakan kod Terdapat banyak cara untuk menyemak kod anda mengikut ayat, atau semak kesempurnaan dan ketepatan kod ujian anda, kemudian jalankan kes ujian anda. Yang terakhir lebih mudah.
Apabila kod ditukar, seperti membetulkan pepijat, sukar untuk menjamin sama ada perubahan anda akan menjejaskan bahagian lain yang bergantung pada kod anda. Dalam era ujian manual, terdapat sesuatu yang dipanggil ujian regresi, iaitu untuk menguji semula sistem anda selepas anda membetulkan pepijat. Tetapi jika anda sudah mempunyai kes ujian yang lengkap, laksanakan arahan secara langsung.
Apabila anda memfaktorkan semula kod anda, begitu juga.

2. Bagaimana untuk menambah baik kes ujian anda

Sebelum memasuki peringkat penghalusan, mula-mula bercakap tentang cara anda akan melaksanakan kes ujian.

describe Meme do

 before do
  @meme = Meme.new
 end

 describe "when asked about cheeseburgers" do
  it "must respond positively" do
   @meme.i_can_has_cheezburger?.must_equal "OHAI!"
  end
 end

 describe "when asked about blending possibilities" do
  it "won't say no" do
   @meme.will_it_blend?.wont_match /^no/i
  end
 end
end

Kod di atas berasal daripada minitest Ruby. Blok kod yang terkandung sebelum ini adalah apa yang perlu dilakukan sebelum melaksanakan kes ujian berikut Ia biasanya juga menyokong kaedah yang sepadan untuk dilaksanakan selepas kes ujian dilaksanakan. Beberapa pertimbangan kecil dibuat dalam setiap kes penggunaan.

Perenggan pertama menyebut beberapa kandungan ujian yang sering terlibat dalam ujian manual Berikut adalah 2 dan 3 daripadanya untuk penjelasan. Semasa menjalankan ujian berkaitan pangkalan data, anda perlu memasukkan sekeping data ujian dalam sebelum dan memadam data ujian dalam selepas. Dalam kes ujian tengah, ketepatan kod disahkan dengan melaksanakan kaedah yang sepadan Selepas pelaksanaan selesai: semak perubahan data/semak sama ada terdapat pengecualian yang dijangkakan/sama ada hasil yang dijangka dikembalikan. Jika ia adalah antara muka, ia adalah untuk memulakan permintaan yang sepadan melalui kod, dan kemudian menyemak sama ada kandungan yang dikembalikan mengembalikan hasil yang dijangkakan Jika perlu, semak sama ada data dalam pangkalan data memenuhi perubahan yang dijangkakan.

Anda kini mempunyai kes ujian, tetapi masih ada kes khas yang perlu dipertimbangkan. Saya kini telah menulis kes ujian yang agak lengkap untuk fungsi Selepas menjalankannya, saya lulus ujian, tetapi saya mendapati bahawa masih terdapat ralat untuk fungsi itu dalam log dalam talian. Selepas menyemak, saya mendapati bahawa cabang tertentu fungsi tidak diuji semasa ujian sebelum ini berlaku bahawa sesuatu dalam talian berlaku untuk dijalankan ke cawangan ini bahawa semua kod adalah betul? Apa yang perlu diperkenalkan di sini ialah konsep yang dipanggil liputan kes ujian Pada asasnya setiap bahasa akan mempunyai pelaksanaan yang sepadan. Melalui liputan kes ujian, kami boleh memberitahu anda secara kuantitatif sama ada kes ujian anda telah menjalankan semua kod dalam fail tertentu Apa yang anda perlu lakukan ialah memastikan liputan anda kekal pada 100% sebanyak mungkin.

Dalam satu segi, kes ujian dan liputan ujian ialah alat yang digunakan untuk meningkatkan keyakinan pembangun terhadap kod mereka sendiri. Walau bagaimanapun, mereka tidak maha kuasa. Selalu ada kemungkinan kehilangan beberapa parameter dalam kes ujian Sudah tentu, kod anda tidak ditulis untuk kemungkinan ini Pada akhirnya, liputan kes ujian hanya boleh memberitahu anda kod yang anda tulis . Saya telah mengujinya, tetapi tiada apa yang boleh anda lakukan tentang kemungkinan yang anda tidak pertimbangkan. Oleh itu, tulis kod ketat sebanyak mungkin Sebagai contoh, gunakan === dan bukannya == dalam JavaScript sebanyak mungkin, gunakan piawaian pengaturcaraan jenis kuat, dsb., untuk mengurangkan potensi risiko yang disebabkan oleh menerima parameter yang terlalu besar. julat.

3. Bagaimana reka bentuk kod memudahkan penulisan kes ujian

Seluruh Web (tidak terhad kepada web) biasanya merangkumi tiga peringkat kod - pemprosesan dan pengiraan data tulen, melibatkan pangkalan data dan melibatkan protokol rangkaian tertentu. Antaranya, operasi data tulen adalah terutamanya fungsi atau kod lain yang berurusan dengan operasi biasa Apabila ia datang kepada pangkalan data, ia adalah M dalam MVC dalam erti kata tradisional Apabila ia berkaitan dengan protokol rangkaian, ia adalah C yang sepadan. Tiga ujian ini sepadan dengan tiga item pertama kandungan ujian biasa dalam bahagian pertama.

Oleh kerana tahap C biasanya melibatkan pemaparan halaman dan simulasi protokol yang sepadan, biasanya memfokuskan ujian pada fungsi dan kod berkaitan pangkalan data boleh mengurangkan kerumitan kod kes ujian, yang memerlukan kod Pengawal Sedikit mungkin . Beberapa cadangan semasa untuk aplikasi yang lebih kompleks:

Letakkan pengesahan asas data dalam lapisan M Jika dibangunkan menggunakan Ruby, ActiveRecord dan Mongoid kedua-duanya menyediakan fungsi pengesahan yang sangat mudah.
Cuba gunakan mod Pub/Sub dalam kod dengan beberapa cangkuk yang disediakan dalam ORM untuk mencapai komunikasi antara Model. Sebagai contoh, apabila A menerbitkan mesej apabila ia dibuat, B mengubah suai salah satu nilai atributnya sendiri selepas mendengar mesej itu.
Gunakan mod Perintah untuk mengekstrak beberapa fungsi bukan perniagaan daripada sistem, seperti penghantaran e-mel.
Rujukan untuk cadangan di atas: Laravel wisper resque

4. Idea

Kandungan di atas mengelakkan kes ujian yang memerlukan penyahpepijatan bersama hujung hadapan dan belakang Kandungan berikut tertumpu terutamanya pada kawasan ini. Ruby sudah mempunyai beberapa pelaksanaan yang elegan ke arah ini Jika anda berminat, anda boleh pergi terus ke Capybara terlebih dahulu.

Dengan populariti siri pemacu penyemak imbas termasuk Selenium Phantomjs dan Watir berdasarkan yang pertama, mengawal penyemak imbas menggunakan kod bukan lagi satu perkara yang rumit. Berdasarkan keupayaan ini, anda boleh cuba membahagikan ujian berasaskan hadapan kepada empat langkah:

等待某标志性元素出现（例如等待页面载入玩，或者某个内容异步加载出现）
模拟用户操作，这里的操作包括且不局限于用户点击、用户输入
等待反馈中标志性元素出现（例如某某输入框出现）
判断内容，是否符合预期
基于这个流程，可以解决绝大多数的前端测试。但是单纯依靠这个流程任然不够，因为页面中可能出现例如验证码这样的阻碍元素，在不修改代码的前提下，可以尝试通过数据库/缓存来取到这些内容。同样，和测试接口相同，这里也涉及到在测试前数据库中插入测试数据，测试用例执行后严重数据库里面数据变化，以及全部测试完毕后删除测试数据的内容。最终导致这块测试用例代码的实现需要同时对前端后端有一定的了解。目前还在考虑在借鉴 Capybara 的基础上，设计出更加通用的方案。

最后贴一段 Capybara 的代码结束这段内容：

feature "Signing in" do
 background do
  User.make(:email => 'user@example.com', :password => 'caplin')
 end

 scenario "Signing in with correct credentials" do
  visit '/sessions/new'
  within("#session") do
   fill_in 'Email', :with => 'user@example.com'
   fill_in 'Password', :with => 'caplin'
  end
  click_button 'Sign in'
  expect(page).to have_content 'Success'
 end

 given(:other_user) { User.make(:email => 'other@example.com', :password => 'rous') }

 scenario "Signing in as another user" do
  visit '/sessions/new'
  within("#session") do
   fill_in 'Email', :with => other_user.email
   fill_in 'Password', :with => other_user.password
  end
  click_button 'Sign in'
  expect(page).to have_content 'Invalid email or password'
 end
end