[Kompilasi dan Perkongsian] Beberapa rangka kerja ujian yang boleh digunakan dalam Node.js

NodApakah rangka kerja ujian yang boleh digunakan? Artikel berikut akan berkongsi dengan anda beberapa rangka kerja ujian Node.js saya harap ia akan membantu anda!

Nota editor: Pengarang artikel ini ialah Tianzhu, seorang jurutera di Ant Group Node.js Mula-mula, dia akan memperkenalkan kelas yang biasa digunakan perpustakaan di setiap bahagian Pada akhir artikel, Mari kita bincangkan sama ada ujian unit perlu dibincangkan bersama.

Perpustakaan dan alatan yang biasa digunakan

Pelaksana kes ujian

mocha dan jest digunakan lebih kerap. ujian nod baharu rasmi masih digilap dan masa depan adalah menjanjikan.

$ mocha

  test/egg-view-ejs.test.js
    render
      ✓ should render with locals
      ✓ should render with cache
      ✓ should render with layout
      ✓ should render error
    renderString
      ✓ should renderString with data
      ✓ should renderString error

  6 passing (398ms)

Walaupun terdapat begitu ramai Pelari, standard keluaran mereka semuanya dalam format TAP, dan kemudian hasilnya dikeluarkan melalui Pemberita yang berbeza.

Statistik liputan

Menulis satu ujian sahaja tidak mencukupi dengan alat kadar liputan.

sebelum ini istanbuljs, dan kemudian pengarang menulis semula nyc Mereka terutamanya memikul dua tanggungjawab: satu ialah menterjemah kod untuk memasukkan kod cerucuk, dan satu lagi adalah Menyokong pelbagai Wartawan untuk menjana laporan liputan.

Kemudian, statistik liputan terbina dalam V8

, yang bermaksud tidak perlu menterjemah kod lagi dan pengumpulan data liputan disokong secara asli.

Kemudian pengarang ini menulis c8 yang memfokuskan pada penjanaan laporan liputan.

Assert class library

Untuk mengesahkan hasil pembolehubah, assert adalah penting.

Dari segi sejarah: expect.js, should.js, chai dan power-assert, jest juga mempunyai jangkaan terbina dalam sendiri.

Tetapi kini tegas/ketat rasmi Node.js sebenarnya cukup bagus.

Antaranya, power-assert adalah apa yang kami di EggJS telah menggunakan saya juga memperoleh keuntungan bertahun-tahun yang lalu: "Mungkin perpustakaan JS Assert yang terbaik - Pakaian Baru Kaisar ".

const assert = require('power-assert');

describe('test/showcase.test.js', () => {
  const arr = [ 1, 2, 3 ];

  it('power-assert', () => {
    assert(arr[1] === 10);
  });
});

// output:
4) test/showcase.test.js power-assert:

      AssertionError:   # test/showcase.test.js:6

  assert(arr[1] === 10)
         |  |   |
         |  2   false
         [1,2,3]

  [number] 10
  => 10
  [number] arr[1]
  => 2

PS: Jika anda ingin mengesahkan kandungan fail, saya juga telah menulis assert-file, dialu-alukan untuk mencubanya.

Perpustakaan Kelas Mock & Stub

Oleh kerana ia adalah ujian unit, selalunya perlu untuk mensimulasikan persekitaran atau respons hiliran.

sinonjs tidak buruk, menyokong olok-olok dan rintisan, dsb. jest juga mempunyai perpustakaan olok-olok terbina dalam sendiri.

Jika ia adalah ujian HTTP, nock sangat berkuasa dan boleh membantu anda mengejek tindak balas pelayan.

nock('http://www.example.com')
  .post('/login', 'username=pgte&password=123456')
  .reply(200, { id: '123ABC' })

Walau bagaimanapun, perpustakaan permintaan Node.js undici rasmi juga mempunyai keupayaan Mock terbina dalam.

Terdapat juga istilah yang dipanggil syot kilat, yang bermaksud lambakan data semasa operasi dan terus menggunakannya sebagai data olok-olok untuk ujian seterusnya, yang boleh meningkatkan kecekapan menulis ujian ke tahap tertentu.

Pustaka ujian HTTP

Untuk menguji senario Pelayan HTTP, pustaka paling hebat adalah penting.

describe('GET /users', function() {
  it('responds with json', async function() {
    return request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200)
      .then(response => {
        assert(response.body.email, 'foo@bar.com');
      });
  });
});

Pustaka ujian baris perintah

Salah satu senario penggunaan Node.js ialah baris arahan CLI, seperti Webpack, Babel, dll., yang sendiri juga memerlukan ujian Tunggal.

Cadangan ini ialah apa yang kami tulis:

• GitHub - node-modules/clet: Command Line E2E Testing

• GitHub - nod-modules/coffee: Uji baris arahan pada Node.js

  import { runner, KEYS } daripada 'clet';

  it('should berfungsi dengan boilerplate', async () => tunggu pelari() .cwd(tmpDir, { init: benar }) .spawn('npm init') .stdin(/nama:/, 'contoh') // tunggu stdout, kemudian balas .stdin(/version:/, Array(9) baharu.isi(KEYS.ENTER)) .stdout(/"name": "example"/) // sahkan stdout .notStderr(/npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // sahkan fail });

Alat ujian automasi halaman web

Merangkak halaman dengan ringan, anda boleh terus menggunakan perpustakaan permintaan HTTP, disyorkan undici .

Untuk mensimulasikan pelaksanaan sebenar penyemak imbas, yang awal ialah selenium dan phantomjs.

Kemudian Google secara rasmi mengeluarkan puppeteer Disebabkan pengumpulan Chromium dan berdasarkan protokol devtools-protocol, ia menjadi sangat popular dan membunuh dua yang pertama. Produk pesaing yang serupa termasuk pengarang drama dan cypress.

Sebenarnya, macacajs ialah alat ujian berbilang terminal yang menyokong ujian APP mudah alih dan APP desktop selain penyemak imbas Ia adalah sumber terbuka oleh jurutera dari pasukan Yuque.

Perkhidmatan penyepaduan berterusan

Apabila kami menulis sumber terbuka, kami sering memerlukan perkhidmatan penyepaduan berterusan automatik untuk membantu kami menguji.

Pemain dalam medan ini termasuk: Travis, Appveyor, GitHub Actions, dsb.

Sekarang saya pada asasnya menggunakan GitHub Actions, tahap penyepaduan sangat hebat.

Perbincangan: Adakah ujian unit perlu?

Tidak dinafikan bahawa ujian unit adalah sangat penting. Ia adalah kebolehan yang diperlukan dan kualiti profesional seorang pengaturcara yang berkelayakan.

Sudah tentu, kami bukan fanatik liputan 100% Dalam banyak kes, kami perlu mengejar titik keseimbangan ROI.

1. Adakah ujian unit menulis membuang masa?

Pertama sekali, izinkan saya membetulkan pandangan orang baru yang biasa: Menulis ujian unit adalah membuang masa?

Malah, menulis ujian unit akan menjimatkan masa anda Sebab bagi pandangan intuitif balas itu ialah syarat perbandingan selalunya tidak objektif. Kita perlu mempertimbangkan kos regresi selepas mengubah suai kod dua kali di bawah keperluan kualiti yang sama.

Untuk perbandingan yang adil, selain mempertimbangkan "masa untuk menulis satu ujian", apa yang mudah diabaikan ialah "masa untuk ujian regresi selepas setiap pengubahsuaian kod":

• Menulis ujian tunggal Dalam kes ujian, buat olok-olok pelbagai cabang pada peringkat awal, dan masa untuk ujian regresi ialah mengetik papan kekunci;
• Jika anda tidak menulis satu ujian , anda perlu mengemas kini kod ke dalam aplikasi, dan kemudian mensimulasikan pelbagai Ujian secara manual dalam situasi berbeza, seperti membuka penyemak imbas dan mengklik di banyak tempat yang berbeza.

Sepintas lalu jelas bagaimana kedua-duanya mengambil masa.

Ia tidak lebih daripada pelaburan awal, kos penyelenggaraan, penekanan pada kualiti pulangan dan membuat keputusan selepas menimbang.

Sudah tentu, banyak senario yang saya nyatakan ialah perpustakaan rangka kerja (termasuk bahagian hadapan dan Node.js), aplikasi sisi pelayan, alatan baris arahan, dll. Memang benar bahawa terdapat beberapa perubahan besar Untuk aplikasi dengan paparan bahagian hadapan berorientasikan UI atau halaman aktif yang cepat naik dan turun, kos penyelenggaraan ujian tunggal yang sepadan sememangnya sangat tinggi Pada masa ini, adalah munasabah untuk meninggalkan ujian tunggal dengan sewajarnya daripada beberapa cawangan bukan teras berdasarkan ROI.

Tetapi kita mesti faham bahawa ini adalah pilihan terakhir Kita boleh mengurangkan kos penyelenggaraan ujian unit melalui pelbagai cara, tetapi kita tidak boleh mendakwa bahawa ujian unit tidak berguna.

Terdapat juga ujian regresi separa automatik dalam medan bahagian hadapan, iaitu untuk mengautomasikan perbandingan berdasarkan perbezaan, dan kemudian mengingatkan pemilik untuk memberi perhatian kepada kesan perubahan. Ini adalah sama seperti perpustakaan alat di atas, yang semuanya ada di sini untuk membantu mengurangkan kos menulis ujian tunggal.

2. Bukankah ujian unit sepatutnya ditulis oleh pengaturcara?

Ini juga pandangan yang salah Ujian unit harus ditulis oleh pengaturcara sendiri, kerana ia adalah kod anda sendiri dan anda bertanggungjawab untuknya . Mana-mana pasukan yang mempunyai sedikit penyeragaman perlu mempunyai ujian CI semasa menyerahkan kod, jika tidak, tiada kerjasama Semakan Kod yang berkualiti.

Pelajar ujian bertanggungjawab untuk kerja peringkat lebih besar seperti ujian integrasi, ujian regresi, ujian hujung ke hujung, dsb.

Pembahagian kerja adalah berbeza, tolong jangan salahkan orang lain.

jadi...

Ujian unit penulisan adalah kualiti profesional asas bagi pengaturcara. anda boleh tukar ganti ROI.

Untuk lebih banyak pengetahuan berkaitan nod, sila lawati: tutorial nodejs!

Atas ialah kandungan terperinci [Kompilasi dan Perkongsian] Beberapa rangka kerja ujian yang boleh digunakan dalam Node.js. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!