JWT 是一個老牌的套件,從 nuget 上來看他,甚至還比 System.IdentityModel.Tokens.Jwt 還要資深,使用起來也相當的簡單
以下是我的使用過程分享
JWT 是一個老牌的套件,從 nuget 上來看他,甚至還比 System.IdentityModel.Tokens.Jwt 還要資深,使用起來也相當的簡單
以下是我的使用過程分享
之前有寫過用 TestServer 測試 Web API,[ASP.NET Identity] 使用 Microsoft.Owin.Testing 測試 OAuth Server 和 Web API,某些情境使用上會失效,比如 Redirect,後來又改用了 OWIN,就比較沒有問題了
https://dotblogs.com.tw/yc421206/archive/2014/07/28/146082.aspx 根據上篇,可輕易地在專案建立出不同環境的組態設定,但是 TFS 上的 Build 沒有正常的切換環境,測試專案的連線字串沒有根據我期望的切換,不像 Web 那樣,原來還需要一些設定,以下分享我成功的方法。
續上篇,https://dotblogs.com.tw/yc421206/2016/08/02/identity_oauth_owin_setup
隨著功能的演進,原本用 Fiddler 編寫的測試腳本,越來越不容易管理,Web API 的品質也越來越不穩定
有了 TestServer 之後,我的問題就一掃而空,接下來就來分享我的作法,
結果與期望比對,是測試程式碼中最重要的一個步驟,就是用它來取代人眼比對,有關物件比對 91哥的文章有非常詳細的介紹:
https://dotblogs.com.tw/hatelove/2014/06/06/how-to-assert-two-collection-equal
https://dotblogs.com.tw/hatelove/2016/03/28/compare-object-equality-with-expected-objects
當測試程式碼用的是複雜型別,會比對型別中的屬性狀態(值),用它來決定是否通過驗證,最直接的方式就是跑迴圈一個一個比,這樣做不是很聰明,也不夠快,太費力
我會使用以下物件來完成我的工作
在這裡我分享我常用的比對方式...
開發 Web 或多或少會使用到 HttpContext.Current,為了專注測主要邏輯,會隔離 HttpContext.Current,不要因為它而導致測試無法運行,我在這裡列出了一些隔離技巧
集成測試主要是測試個元件之間的互動是否如預期,在這個階段的測試,我會把程式進入點 UI Layer 換成單元測試專案,由測試專案取代之,為什麼不是直接從UI測,原因很簡單,因為 UI 的變化太快了,一方面為了減少因 UI 改變而衍生出額外的工作,另一方面則為了提高測試程式碼的重用性,所以我會從 BLL 測試
三層式架構,物件彼此之間的關係,如下圖:
[C#.NET] 使用 Fluent Assertions 驗証例外
[C#.NET] 用了 Fluent Assertions,我的測試程式碼也會說話
[C#.NET] NUnit Test 初體驗