這篇文章主要介紹“Node.js可運(yùn)用的測(cè)試框架有哪些”，在日常操作中，相信很多人在Node.js可運(yùn)用的測(cè)試框架有哪些問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Node.js可運(yùn)用的測(cè)試框架有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！
舞陽(yáng)網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),舞陽(yáng)網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為舞陽(yáng)上千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的舞陽(yáng)做網(wǎng)站的公司定做！
mocha 和 jest 用的比較多。官方新出了個(gè) node test 還在打磨中，未來(lái)可期。
$ 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)
雖然有這么多 Runner，不過(guò)它們的輸出標(biāo)準(zhǔn)都是 TAP 格式，然后通過(guò)不同 Reporter 輸出結(jié)果。
光寫(xiě)單測(cè)還不夠，我們需要知道是否覆蓋了代碼的所有分支流程，所以一般還要搭配代碼覆蓋率工具。
之前是 istanbuljs，后面作者重寫(xiě)了個(gè) nyc，它們主要承擔(dān) 2 個(gè)職責(zé)：一是把代碼進(jìn)行轉(zhuǎn)譯從而插入打樁代碼，二是支持各種 Reporter 來(lái)生成覆蓋率報(bào)告。
再后來(lái) V8 內(nèi)置了覆蓋率統(tǒng)計(jì)
，即無(wú)需再轉(zhuǎn)譯代碼了，原生支持覆蓋率數(shù)據(jù)采集。
然后又是這個(gè)作者寫(xiě)了個(gè) c8 專(zhuān)注于生成覆蓋率報(bào)告。
校驗(yàn)變量結(jié)果，必不可少的要用到 assert。
歷史上出現(xiàn)過(guò)：expect.js 、should.js、chai 以及 power-assert，jest 也內(nèi)置了自己的 expect。
不過(guò)現(xiàn)在 Node.js 官方的 assert/strict 其實(shí)也還不錯(cuò)。
重慶分公司
重慶分公司
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因?yàn)槭菃卧獪y(cè)試，所以經(jīng)常會(huì)需要模擬環(huán)境或下游的響應(yīng)。
sinonjs 還不錯(cuò)，支持 mock 和 stub 等。jest 同樣也內(nèi)置了自己的 mock 庫(kù)。
如果是 HTTP 測(cè)試的話(huà)，nock 很強(qiáng)大，可以幫你 Mock 服務(wù)端響應(yīng)。
nock('http://www.example.com')
.post('/login', 'username=pgte&password=123456')
.reply(200, { id: '123ABC' })不過(guò) Node.js 官方出的 undici 請(qǐng)求庫(kù)也內(nèi)置了 Mock 能力。
還有個(gè)術(shù)語(yǔ)叫 snapshot，即在運(yùn)行的時(shí)候把數(shù)據(jù) dump 下來(lái)，直接作為下次測(cè)試的 mock 數(shù)據(jù)，能一定程度上提升編寫(xiě)測(cè)試的效率。
測(cè)試 HTTP Server 場(chǎng)景，必不可少的就是 supertest 這個(gè)庫(kù)。
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');
});
});
});Node.js 的一大使用場(chǎng)景是命令行 CLI，如 Webpack、Babel 這些，它們本身也是需要有單測(cè)的。
這塊推薦我們寫(xiě)的：
GitHub - node-modules/clet: Command Line E2E Testing
GitHub - node-modules/coffee: Test command line on Node.js
import { runner, KEYS } from 'clet';
it('should works with boilerplate', async () => { await runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // wait for stdout, then respond .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // validate stdout .notStderr(/npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // validate file });
輕量的爬頁(yè)面，可以直接用 HTTP 請(qǐng)求庫(kù)即可，推薦 undici。
模擬瀏覽器真實(shí)執(zhí)行的話(huà)，早期是 selenium 和 phantomjs。
然后 Google 官方出了 puppeteer，由于有 Chromium 的積累，基于 devtools-protocol 協(xié)議，很快就廣受歡迎，干掉了前兩者。同類(lèi)的競(jìng)品還有 playwright 和 cypress。
順便安利下 macacajs，一個(gè)多端的測(cè)試工具，除了瀏覽器外還支持移動(dòng) APP 和桌面 APP 的測(cè)試，是語(yǔ)雀團(tuán)隊(duì)的工程師開(kāi)源的。
我們寫(xiě)開(kāi)源的時(shí)候，經(jīng)常需要自動(dòng)化的持續(xù)集成服務(wù)來(lái)幫我們測(cè)試。
這個(gè)領(lǐng)域的玩家有：Travis 、Appveyor、GitHub Actions 等。
現(xiàn)在基本上都是用 GitHub Actions 了，集成程度太爽了。
毋庸置疑，單元測(cè)試是非常重要的，它是一名合格的程序員的必要能力和職業(yè)素養(yǎng)。
當(dāng)然，我們也不是原教旨的 100% 覆蓋率狂徒，很多情況下需要追求 ROI 的平衡點(diǎn)。
首先，我先糾正一個(gè)常見(jiàn)的新人觀(guān)點(diǎn)：寫(xiě)單元測(cè)試很浪費(fèi)時(shí)間？
實(shí)際上，寫(xiě)單元測(cè)試反而會(huì)節(jié)省你的時(shí)間，之所以有那個(gè)反直覺(jué)的觀(guān)點(diǎn)，往往之于對(duì)比的條件不客觀(guān)。我們需要考慮二次修改代碼后，在同等質(zhì)量要求的情況下，回歸的成本。
公平的對(duì)比，除了考慮『寫(xiě)單測(cè)時(shí)間』外，容易忽略的是『每次修改代碼后回歸測(cè)試的時(shí)間』：
寫(xiě)單測(cè)的情況下，前期造好各種分支 Mock，回歸測(cè)試的時(shí)間就是敲一下鍵盤(pán)；
不寫(xiě)單測(cè)的情況下，你需要把代碼更新到應(yīng)用中，然后手動(dòng)模擬各種情況來(lái)測(cè)試，譬如要打開(kāi)瀏覽器，點(diǎn)擊很多不同的地方。
這兩個(gè)耗時(shí)如何，一目了然。
無(wú)非是 前期投入+維護(hù)成本+對(duì)回歸質(zhì)量的重視程度，權(quán)衡之后的決策，每個(gè)公司都有自己的尺度。
當(dāng)然，我提的很多場(chǎng)景都是 框架類(lèi)庫(kù)（包括前端和 Node.js）、服務(wù)端應(yīng)用、命令行工具等方面，確實(shí)在一些變化較大的前端偏 UI 展示的應(yīng)用或者快上快下的活動(dòng)頁(yè)面，對(duì)應(yīng)的單測(cè)維護(hù)成本確實(shí)很高，這時(shí)候可以基于 ROI 去適當(dāng)放棄某些非核心分支的單測(cè)，這是合理的。
但我們要清楚這是不得已的取舍，我們可以通過(guò)各種手段去降低單測(cè)的維護(hù)成本，但我們唯獨(dú)不能去宣稱(chēng)單元測(cè)試沒(méi)什么用。
在前端領(lǐng)域還有一種半自動(dòng)化回歸的測(cè)試，就是基于 diff 的方式去自動(dòng)化對(duì)比，然后提醒 Owner 去注意變化影響。這就跟上面那些工具類(lèi)庫(kù)一樣，都是來(lái)幫助減少編寫(xiě)單測(cè)的成本的。
這也是一個(gè)錯(cuò)誤的觀(guān)點(diǎn)，單元測(cè)試是應(yīng)該程序員自己來(lái)寫(xiě)的，因?yàn)槭悄阕约旱拇a，要為此而負(fù)責(zé)，這是一種職業(yè)素養(yǎng)。任何一個(gè)稍微有點(diǎn)規(guī)范的團(tuán)隊(duì)，提交代碼都是需要有 CI 測(cè)試的，否則無(wú)法 有質(zhì)量的 Code Review 協(xié)作。
測(cè)試同學(xué)負(fù)責(zé)的是集成測(cè)試、回歸測(cè)試、端到端測(cè)試等更大層面的工作。
到此，關(guān)于“Node.js可運(yùn)用的測(cè)試框架有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！
