一個關於test測試腳本的pakcage.json配置文件

設想你正在開發這樣的項目，這個項目慢慢會變得越來越龐大，所以如果在項目中僅使用一個單獨測試文件，會感覺到一片混亂。這將會導致代碼的可讀性變得越來越差，最後必然導致出錯。所以你或許會想為某些相關的代碼編寫單獨的測試文件。當程序遇到問題的時候，也許你只想每次執行一個文件來幫助你查找問題。

首先，讓我們討論什麼是測試裝置？在Node里，測試裝置就是一個可運行的命令行腳本，在這個腳本中，你可以輸入腳本名稱來運行腳本。基本來說，它必須可以執行一組測試文件，並且當發生錯誤時，它能夠將錯誤展示出來。當一個斷言失敗時，它必將導致一個異常拋出，對此我們不需要做任何特別的操作，要麼該命令腳本將以返回編碼0安靜地退出執行。

通過在上面的配置文件里使用node test-runner.js test.js test2.js將其設置為test的腳本，這就使得其他的開發人員可以直接在命令行里輸入npm test來運行你的測試腳本。這比單獨記住一些特定的命令要方便簡單得多了。

接下來，展開上面這個例子以進一步說明測試裝置到底是怎麼工作的。一個測試裝置就是一個用於運行一組測試腳本的Node程序。因此，我們可以為這樣一個程序提供一組需要測試的文件，一旦有任何一個測試失敗，它都可以將相應的堆棧跟蹤信息展示出來以方便我們分析失敗的源頭。另外，每當有任何一個測試失敗時，這個測試裝置程序都會返回一個非零狀態並退出運行。這就使得我們的測試可以以一種自動化的方式來運行，即其他的軟體並不需要通過將實際的測試文本輸出結果進行轉換來判斷測試失敗與否，也就說這使得這個過程變得更加簡單。這其實也就是持續集成伺服器工作的原理：每當有新的代碼往類似於Git這樣的源代碼管理器提交時，持續集成伺服器就可以自動化運行所有的測試。

it()函數聲明一個測試用例。

我們可以看看當一個測試失敗的時候將會是什麼樣的情況。

這個測試還會繼續運行。

上面的it函數看上去有點奇怪，但是它是一個全局的函數，這個函數是由測試框架提供的。它用來為每一個測試用例提供一個方便理解的名字。上面的例子中也包含了一個會失敗的測試場景，這樣我們可以看看當發生錯誤的時候測試裝置會有什麼的反應。儘管前面的測試已經失敗了最後一個測試用例會一直運行到結尾。

現在，我們來看看最後一個測驗代碼：接下來的代碼清單里包含了一個可以用於執行例子中測試文件的一個程序

將it函數定義成一個全局的函數。

根據出現的異常列印出結果。

輸出錯誤堆棧以有助於分析錯誤源頭。

每一個傳入命令行的文件都會被運行。

有測試失敗，當程序退出的時候，返回一個非零的錯誤代碼。

為了運行上面的例子，你可以將測試文件作為參數傳入：node test-runner.js test.js test2.js test-n.js。上面的it函數定義成了一個全局的函數，將其命名成it，也使得整個測試和輸出看上去符合人們的邏輯習慣。即使當有錯誤列印出來的時候，看上去也是情理之中的事情。因為it函數接收一個測試用例和一個回調，這個回調函數可以在我們所期望的條件下運行。在上面的例子中，也就是說，可以通過catch的方式來捕獲失敗的斷言並且將錯誤反饋給用戶。

上面的程序通過調用require將所有要測試的文件都以參數的形式傳入到命令行中。當然，如果要讓我們上面的程序變得更加完善，那麼文件處理的部分就需要變得更加複雜，就比如說，需要支持通配符。當有測試用例失敗的時候，exitCode變數就會被設置上一個非零的值。並且這個值會在進程式控制制的事件process.exit中返回出去。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！