Node為中間件注入創建seams

中間件很靈活，可以組合使用。模塊化的方式使得基於Connect的應用開發起來很是愉快。但是中間件有一個缺點，就是難以測試。這一節的技巧是如何通過創建seams來處理相關的問題。你在使用中間件，這讓應用測試變得比較麻煩。在測試持續過程中找出用於替換中間件的seams。在計算機中，seam這個詞通常是用來描述可以用於編輯修改源代碼的位置。這個概念在Stephen Vance在他的書Quality Code:Software Testing Principles,Practices,and Patterns中被擴展應用到類似JavaScript的語言中。

在代碼中seam在測試環境中提供了一種方式來控制代碼執行。任何地方我們可以執行、覆蓋、注入或者控制代碼都可以是seam。這其中一個例子是源於Connect的中間件csrf。它創建了一個session變數，可以在表單中引入來防止跨站請求攻擊。你有一個web應用是允許註冊用戶創建日曆項。如果你的網站沒有使用CSRF保護，其他人可以創建一個web頁面來欺騙你的用戶刪除日曆中的內容。這個攻擊看起來可能是這樣的：

用戶的瀏覽器還是會載入託管在外部網站上的圖片。但是它以一種潛在危險的方式引用了你網站。為了防止這種情況的發生，每一次請求中會隨意產生一個token來插入到表單中。攻擊者無法拿到token，就無法進行有效攻擊。不幸的是，簡單地添加express.csrf到渲染表單的路由並不能進行完整的測試。測試用例一定要經過表單的第一次載入才能提交POST請求到路由處理器中，而這過程中一定生成了包含CSRF token的session變數。為了解決這個問題，你需要把express.csrf納入控制之中。重構它來創建一個seam：將其放在包含其他自定義中間件的模塊中去，在測試過程中去修改它。你沒有必要測試express.csrf，因為Express和Connect的作者已經幫你做了測試——你需要的是在測試中改變它的行為。

有其他兩個選擇可以採用：檢查process.env.NODE_ENV是否設置為test，然後到僅用於測試版本的CSRF中間件分支，或者在express.csrf的內部打補丁來讓你可以提取那個密碼的token。這兩種方式都有問題：第一種方式意味著不可能有100%的代碼覆蓋率——你生產環境的代碼不得不包括測試代碼。第二種方式有可能很脆弱——如果Connect在未來修改了CSRF的功能就很可能有影響。我們使用的基於seam的概念，要求你創建一個中間件文件，如果你沒有。這只是一個文件用來把你所有的中間件都組織起來成為一個模塊來方便載入。然後你需要創建一個方法把express.csrf給包裹起來，或者直接返回它。一個基礎的例子如下所示。

var express = require("express");

創建一個用來注入其他中間件的地方。這所做的一切就是把原始的csrf中間件給暴露出來，但是現在它在測試過程中注入不同的行為則要容易得多。下邊的列表會展示一個測試是怎麼樣的。

首先載入中間件列表，然後替換它的csrf方法。

這裡阻止設置_csrf的值。

應該返回200，而不是403。

這個測試在處理其他事情之前，先載入我們自定義的中間件模塊，然後替換掉csrf方法。當它載入app然後使用SuperTest發起一個請求時，Express會使用我們注入的中間件，因為middleware.js會被緩存起來。設置_csrf的值以防任何一個視圖依賴它，然後請求應該是返回200而不是403（forbidden）。這看起來我們好像並沒有做多少事情，但通過重構express.csrf載入的方式，我們可以以一種更方便測試的方式來允許我們的應用。你通常可能會創建兩個請求來確保csrf中間件的使用，但是這個技術也可以用來做其他的事情。如果在測試中有你不想運行的東西，找到seams來注入需要的行為，或者嘗試使用簡單的JavaScript或者Node模式來創建一個seam——你不需要一個複雜的依賴注入框架，可以利用Node模塊系統的優勢。

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