單元測試的編寫 測試的基本概念（1）

測試的分類

黑盒測試：功能測試，主要驗證功能是否ok 白盒測試：了解**的具體邏輯

單元測試：以最小的單元來實現測試功能，針對小的單元（乙個元件、乙個方法、乙個模組）進行測試。 整合測試：放到一起進行測試。

karma可以把測試跑在真正的瀏覽器上，可以測試ui元件 mocha 提供了乙個測試環境 chai 斷言庫

jest（facebook出的）是基於jsdom的，用js物件來模擬瀏覽器環境（缺陷就是不能測試樣式相關的）不需要整合預設的斷言庫

在src目錄下新建乙個js檔案parser.js

// 對url引數進行解析 a=1&b=2&c=3 => 

const
parser
=(str)
=>
;//()=()表示等號兩邊都要
str.
replace
(/([^&=]+)=([^&=]+)/g
,function()
)return obj;
}const
stringify
=(obj)
=>=$
`)}return arr.
join
('&')}
// 1.會汙染源**2.無法保留測試3.最後我們希望對**進行模組化操作
export
//export匯出的是介面，也就是供別人使用的方法

// 測試檔案一般以.test.js結尾  或者 .spec.js結尾

import
from
'./src/parser'
// describe 套件 => it 一堆用例
describe
('測試parser',(
)=>)}
)})describe
('測試stringify',(
)=>))
.toequal
('a=1&b=2&c=3')}
)})

npm init -y

npm install jest

新建.babelrc檔案

安裝@babel/preset-env(把高階語法轉成低階語法)

npm install @babel/preset-env

npm install @types/jest

npx jest

npx jest --watchall

單元測試（一）基本概念

要減少軟體中的錯誤數目，方法之一就是擁有乙個專業的測試組，其工作就是盡一切可能使軟體崩潰。不幸的是，如果擁有測試組，那麼即使是經驗豐富的開發人員，也會傾向於花費較少的時間來保證 的可靠性。軟體界有一句俗語 開發人員不應該測試他們自己的 這是因為開發人員對自己的 瞭如指掌，他們很清楚如何採用適當的方法...

單元測試的一些基本概念

我們 程式設計師 多多少少都寫過單元測試，有的可能幾年前寫的幾行 比如我 姑且也算寫過吧，但是有些東西還是不是很清楚，比如什麼是單元測試？怎麼才算是好的單元測試？等等很多，查了些資料，總結一下。1 什麼是單元測試 單元測試是一段 通常是乙個方法 呼叫另外一段 隨後檢驗一些假設的正確性。如果假設的結果...

單元測試 單元測試編寫的原則

公司要求提公升單元測試的質量，其中我作為方案和推動的主導，對開發過程中的單元測試，有了一些思考和總結 單元測試編寫的目的，是面向計算機特性的，基於函式的in out，所以單元測試的好幫手就是斷言，通過不斷的構造輸出並對結果進行斷言，我們就可以針對乙個物件以及它的函式，構建出充足的用例去包裹它，以期望...