1. 必須建立乙個 subject 例項
2. subject 例項必須繫結當前執行的執行緒。
shiro 擁有為正在執行的應用程式自動地執行繫結//解除繫結邏輯的建築元件。例如，在 web 應用程式中，當過濾 乙個請求時，shiro 的根過濾器執行該邏輯。但由於測試環境和框架不同，我們需要自己選擇自己的測試框架來執 行此繫結/解除繫結邏輯。
test setup
我們知道在建立乙個 subject 例項後，它必須被繫結執行緒。在該執行緒（或在這個例子中，是乙個 test）完成執行後， 我們必須解除 subject 的繫結來保持執行緒的'clean'. 幸運的是，現代測試框架如 junit 和 testng 已經能夠在本地支援'setup'和'teardown'的概念。我們可以利用這一支援 來模擬 shiro 在乙個「完整的」應用程式中會做些什麼。我們已經在下面建立了乙個你能夠在你自己的測試中使用 的抽象基類——隨意複製和修改如果你覺得合適的話。它能夠在單元測試和整合測試中使用（我在本例中使用 junit， 但 testng 也能夠工作得很好）：
在 abstractshirotest 類中的**使用 shiro 的 threadstate 概念及乙個靜態的 securitymanager。這些技術在測試和框 架**中是很有用的，但幾乎不曾在應用程式**中使用。 大多數使用 shiro 工作的需要確保執行緒的一致性的終端使用者，幾乎總是使用 shiro 的自動管理機制，即 subject.associatewith 和 subject.execute 方法。這些方法包含在 subject thread association 參考文獻中。
unit testing
單元測試主要是測試你的**，且你的**是在有限的作用域內。當你考慮到 shiro 時，你真正要關注的是你的代 碼能夠與 shiro 的 api 正確的執行——你不會想做關於 shiro 的實現是否工作正常（這是 shiro 開發團隊在 shiro 的代 碼庫必須確保的東西）的必要測試。 測試 shiro 的實現是否與你的實現協同工作是真實的整合測試（下面討論）。
exampleshirounittest
由於單元測試適用於測試你的邏輯（而不是你可能呼叫的任何實現），這對於模擬你邏輯所依賴的任何 api 來說是 個很好的主意。這能夠與 shiro 工作得很好——你可以模擬 subject 例項，並使它反映任何情況下你所需的反應，這 些反應是處於測試的**做出的。 但正如上文所述，在 shiro 測試中關鍵是要記住在測試執行期間任何 subject 例項（模擬的或真實的）必須繫結到線 程。因此，我們所需要做的是繫結模擬的 subject 以確保如預期進行。 （這個例子使用 easymock，但 mockito 也同樣地工作得很好）：
正如你所看到的，我們沒有設立乙個 shiro securitymanager 例項或配置乙個 realm 或任何像這樣的東西。我們簡單 地建立乙個模擬 subject 例項，並通過呼叫 setsubject 方法將它繫結到執行緒。這將確保任何在我們測試**中的呼叫 或在**中我們正測試的 securityutils.getsubject()正常工作。 請注意，setsubject 方法實現將繫結你的模擬 subject 到執行緒，且它仍將存在，直到你通過乙個不同的 subject 呼叫 setsubject 或直到你明確地通過呼叫 clearsubject()將它從執行緒中清除。 保持 subject 繫結到該執行緒多長時間（或在乙個不同的測試中用來交換乙個新的例項）取決於你及你的測試需求。
teardownsubject()
在例項中的 teardownsubject()方法使用了 junit 4 的注釋來確保該 subject 在每個測試方法執行後被清除，不管發生 什麼。這要求你設立乙個新的 subject 例項並將它設定到每個需要執行的測試中。 然而這也不是絕對必要的。例如，你可以只每個測試開始時繫結乙個新的 subject 例項（通過 setsubject），也就是 說，使用@before-annotated 方法。但如果你將要這麼做，你可以同時使用@after teardownsubject() 方法來保持對 稱及'clean'。 你可以手動地在每個方法中混合及匹配該 setup/teardown 邏輯或使用@before 和@after 注釋只要你認為合適。所有 測試完成後，abstractshirotest 超類在無論怎樣都會將 subject 從執行緒解除繫結，因為@after 注釋在它的 teardownshiro()方法中。
integration testing
現在我們討論了單元測試的設定，讓我們討論一些關於整合測試的東西。整合測試是指測試跨 api 邊界的實現。例 如，測試當呼叫 b 實現時 a 實現是否工作，且 b 實現是否做它該做的事情。 你同樣也可以在 shiro 中輕鬆地執行整合測試。shiro 的 securitymanager 例項及它所包含的東西（如 realms 和 sessionmanager 等）都是占用很少記憶體的非常輕量級的 pojo。這意味著你可以為每乙個你執行的測試類建立並銷毀 乙個 securitymanager 例項。當你的整合測試執行時，它們將使用「真實的」securitymanager，且與你應用程式中 相像的 subject 例項將會在執行時使用。
exampleshirointegrationtest 下面的例項**看起來與上面的單元測試例項幾乎相同，但這 3 個步驟卻有些不同：
1. 現在有了 step '0'，它用來設立乙個「真實的」securitymanager 例項。
2. step 1 現在通過 subject.builder 構造乙個「真實的」subject 例項，並將它繫結到執行緒。
執行緒的繫結與解除繫結（step 2 和 3）與單元測試例項中的作用一樣。
正如你所看到的，乙個具體的 securitymanager 實現被例項化，並通過 setsecuritymanager 方法使其餘的測試能夠對 其進行訪問。然後測試方法能夠使用該 securitymanager，當使用 subject.builder 後通過呼叫 getsecuritymanager()方 法。 還要注意 securitymanager 例項在@beforeclass 設定方法中只被設定一次——乙個對於大多數測試類較為普遍的做 法。如果你想，你可以建立乙個新的 securitymanager 例項並在任何時候從任何測試方法通過 setseruritymanager 來 設定它——例如，你可能會引用兩個不同的.ini 檔案來構建乙個根據你的測試需求而來的新 securitymanager。 最後，與單元測試例子一樣，abstractshirotest 超類將會清除所有 shiro 產物（任何存在的 securitymanager 及 subject 例項）通過它的@afterclass teardownshiro()方法來確保該執行緒在下個測試類執行時是'clean'的。
海量儲存系列之十三
在上一章中，我們主要介紹了規則引擎中最重要的乙個部分，自動擴容，在今天的章節，我們主要還是介紹一下我們在 tddl中的工程實踐吧。首先從原理開始吧。規則引擎是什麼呢？對應在上述例子裡面，其實就是dbnum pk 3 這個規則。他的變化可能很多，比如對於一致性hash則變為乙個if else 的表示式...
Django反向解析系列之十三
隨著功能的增加會出現更多的檢視，可能之前配置的正規表示式不夠準確，於是就要修改正規表示式，但是正規表示式一旦修改了，之前所有對應的超連結都要修改，真是一件麻煩的事情，而且可能還會漏掉一些超連結忘記修改，有辦法讓鏈結根據正規表示式動態生成嗎？就是用反向解析的辦法。1 在專案urls.py中為inclu...
網路程式設計系列之十三 wireshark安裝檔案衝突
在閱讀freeradius client的原始碼的時候，需要測試並且通過wireshark抓包來看報文結構。在安裝wireshark的過程中遇到了檔案衝突的問題 1 yum y install wireshark 安裝wireshark的文字工具，沒有問題 2 yum y install wires...