Kerangka pengujian apa yang dapat digunakan untuk Node? Artikel berikut akan membagikan kepada Anda beberapa kerangka pengujian Node.js. Saya harap ini dapat membantu Anda! 
Kursus pengenalan singkat Node.js: masuk untuk belajar
Catatan Editor: Penulis artikel ini adalah Tianzhu, seorang insinyur Node.js di Ant Group. Pertama-tama, dia akan memperkenalkan perpustakaan kelas yang umum digunakan di setiap bagian. Di akhir artikel, dia akan membahas apakah pengujian unit diperlukan untuk berdiskusi bersama.
moka dan lelucon biasanya digunakan. Pengujian node resmi baru masih dalam tahap penyempurnaan, dan masa depan cukup menjanjikan.
$moka tes/telur-lihat-ejs.test.js memberikan ✓ harus dirender dengan penduduk setempat ✓ harus dirender dengan cache ✓ harus dirender dengan tata letak ✓ seharusnya membuat kesalahan renderString ✓ harus merenderString dengan data ✓ seharusnya error renderString 6 operan (398ms)
Meski Pelari banyak sekali, namun standar keluarannya semuanya dalam format TAP, dan hasilnya dikeluarkan melalui Reporter yang berbeda.
Menulis satu tes saja tidak cukup. Kita perlu mengetahui apakah semua proses cabang kode tercakup, jadi kita biasanya perlu menggunakan alat cakupan kode.
Dulunya istanbuljs, tapi kemudian penulis menulis ulang nyc. Mereka terutama memikul dua tanggung jawab: satu menerjemahkan kode untuk memasukkan kode tumpukan, dan yang lainnya adalah mendukung berbagai Reporter untuk menghasilkan laporan liputan.
Kemudian, statistik cakupan bawaan V8
, artinya, tidak perlu lagi menerjemahkan kode, dan pengumpulan data cakupan sudah didukung secara asli.
Kemudian penulis ini menulis c8 yang fokus pada pembuatan laporan liputan.
Untuk memverifikasi hasil variabel, pernyataan sangat penting.
Secara historis: Expect.js, Should.js, Chai, dan Power-assert, jest juga memiliki ekspektasi bawaannya sendiri.
Tapi sekarang Node.js resmi menegaskan/ketat sebenarnya cukup bagus.
Diantaranya, power-assert adalah apa yang kami di EggJS telah gunakan. Saya juga menyebutkannya beberapa tahun yang lalu: "Mungkin perpustakaan JS Assert terbaik - Pakaian Baru Kaisar".
const menegaskan = memerlukan('tegaskan kekuatan');
deskripsikan('test/showcase.test.js', () => {
konstanta arr = [1, 2, 3];
itu('menegaskan kekuatan', () => {
menegaskan(arr[1] === 10);
});
});
//keluaran:
4) pernyataan kekuatan test/showcase.test.js:
AssertionError: # tes/showcase.test.js:6
menegaskan(arr[1] === 10)
|
|.2 salah
[1,2,3]
[nomor] 10
=> 10
[angka] arr[1]
=> 2PS: Jika ingin memverifikasi isi file, saya juga sudah menulis file pernyataan, selamat mencobanya.
Karena ini adalah pengujian unit, sering kali diperlukan simulasi respons lingkungan atau hilir.
sinonjs tidak buruk dan mendukung tiruan, stub, dll. jest juga memiliki perpustakaan tiruannya sendiri.
Jika ini adalah pengujian HTTP, nock sangat kuat dan dapat membantu Anda meniru respons server.
nock('http://www.example.com')
.post('/login', 'nama pengguna=pgte&kata sandi=123456')
.reply(200, { id: '123ABC' })Namun, perpustakaan permintaan undici resmi Node.js juga memiliki kemampuan Mock bawaan.
Ada juga istilah yang disebut snapshot, yang berarti membuang data selama operasi dan langsung menggunakannya sebagai data tiruan untuk pengujian berikutnya, yang dapat meningkatkan efisiensi penulisan pengujian sampai batas tertentu.
Untuk menguji skenario HTTP Server, perpustakaan supertest sangat diperlukan.
deskripsikan('DAPATKAN /pengguna', fungsi() {
it('merespon dengan json', fungsi async() {
permintaan pengembalian (aplikasi)
.mendapatkan('/pengguna')
.set('Terima', 'aplikasi/json')
.expect('Tipe Konten', /json/)
.mengharapkan(200)
.lalu(respon => {
menegaskan(response.body.email, '[email protected]');
});
});
});Salah satu skenario penggunaan utama Node.js adalah CLI baris perintah, seperti Webpack dan Babel, yang juga memerlukan pengujian unit.
Inilah yang kami rekomendasikan:
GitHub - node-modul/clet: Pengujian E2E Baris Perintah
GitHub - node-modules/coffee: Uji baris perintah di Node.js
impor { pelari, KUNCI } dari 'clet';
it('harus berfungsi dengan boilerplate', async () => { waiting runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // tunggu stdout, lalu tanggapi .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // validasi stdout .notStderr(/ npm ERR/) .file('package.json', { nama: 'contoh', versi: '1.0.0' }) // validasi file });
Untuk perayapan halaman yang ringan, Anda dapat langsung menggunakan HTTP untuk meminta perpustakaan Unci.
Untuk mensimulasikan eksekusi sebenarnya dari browser, Selenium dan phantomjs digunakan pada masa-masa awal.
Kemudian Google secara resmi merilis dalang. Karena akumulasi Chromium dan berdasarkan protokol devtools, dengan cepat menjadi populer dan mematikan dua yang pertama. Produk pesaing serupa termasuk dramawan dan cemara.
Ngomong-ngomong, saya akan mengunduh macacajs, alat pengujian multi-terminal. Selain browser, ini juga mendukung pengujian aplikasi seluler dan aplikasi desktop. Alat ini bersumber terbuka oleh para insinyur dari tim Yuque.
Saat kami menulis open source, kami sering kali memerlukan layanan integrasi berkelanjutan otomatis untuk membantu kami mengujinya.
Pemain di bidang ini meliputi: Travis, Appveyor, GitHub Actions, dll.
Sekarang saya pada dasarnya menggunakan GitHub Actions, dan tingkat integrasinya sangat keren.
Tidak ada keraguan bahwa pengujian unit sangat penting. Ini adalah kemampuan yang diperlukan dan kualitas profesional dari seorang programmer yang berkualifikasi.
Tentu saja, kami tidak 100% fanatik terhadap cakupan. Dalam banyak kasus, kami perlu mengejar titik keseimbangan ROI.
Pertama-tama, izinkan saya mengoreksi sudut pandang pendatang baru: Apakah menulis unit test hanya membuang-buang waktu?
Faktanya, menulis pengujian unit akan menghemat waktu Anda. Alasan pandangan kontra-intuitif tersebut adalah karena kondisi perbandingan seringkali tidak objektif. Kita perlu mempertimbangkan biaya regresi setelah memodifikasi kode dua kali dengan persyaratan kualitas yang sama.
Sebagai perbandingan yang adil, selain mempertimbangkan "waktu untuk menulis pengujian tunggal", yang mudah diabaikan adalah "waktu untuk melakukan pengujian regresi setelah setiap modifikasi kode":
Saat menulis pengujian tunggal, buat berbagai tiruan cabang pada tahap awal, dan waktu untuk pengujian regresi cukup mengetik di keyboard;
Tanpa menulis satu pengujian pun, Anda perlu memperbarui kode ke dalam aplikasi, lalu secara manual menyimulasikan berbagai situasi untuk pengujian, seperti membuka browser dan mengklik di banyak tempat berbeda.
Sekilas betapa memakan waktu keduanya.
Ini tidak lebih dari investasi awal + biaya pemeliharaan + penekanan pada kualitas pengembalian. Setiap perusahaan memiliki skalanya sendiri ketika mengambil keputusan setelah mempertimbangkannya.
Tentu saja, banyak skenario yang saya sebutkan adalah pustaka kerangka kerja (termasuk front-end dan Node.js), aplikasi sisi server, alat baris perintah, dll. Memang benar bahwa beberapa aplikasi front-end yang mengalami perubahan besar dalam Tampilan UI atau bongkar muat cepat adalah Untuk halaman aktivitas, biaya pemeliharaan pengujian tunggal yang sesuai memang sangat tinggi. Saat ini, masuk akal untuk mengabaikan pengujian tunggal dari beberapa cabang non-inti berdasarkan ROI.
Namun kita harus memahami bahwa ini adalah pilihan terakhir. Kita dapat mengurangi biaya pemeliharaan pengujian unit melalui berbagai cara, namun kita tidak dapat mengklaim bahwa pengujian unit tidak ada gunanya.
Ada juga uji regresi semi-otomatis di bidang front-end, yang didasarkan pada perbedaan untuk mengotomatiskan perbandingan dan kemudian mengingatkan pemilik untuk memperhatikan dampak perubahan. Ini sama seperti pustaka alat di atas, yang semuanya hadir untuk membantu mengurangi biaya penulisan pengujian tunggal.
Ini juga merupakan pandangan yang salah. Tes unit harus ditulis oleh programmer sendiri , karena ini adalah kode Anda sendiri, dan Anda harus bertanggung jawab untuk itu. Tim mana pun dengan sedikit standarisasi memerlukan pengujian CI saat mengirimkan kode, jika tidak, tidak akan ada kolaborasi Tinjauan Kode yang berkualitas.
Siswa tes bertanggung jawab untuk pekerjaan tingkat yang lebih besar seperti pengujian integrasi, pengujian regresi, dan pengujian ujung ke ujung .
Pembagian kerjanya berbeda-beda, jadi mohon jangan salahkan orang lain.
Pengujian unit sangat diperlukan. Menulis pengujian unit adalah kualitas profesional dasar programmer. Tulislah sebanyak yang Anda bisa. Dalam skenario individual, Anda dapat membuat pilihan berdasarkan ROI.