上篇 提到使用 Prism 來建立 Mock Server，經同事反饋，他期望能使用類似像 Wiremock 有 API 可以在測試步驟根據場景快速的定義 Mock Server 的回傳值，而我期望除了用 API 動態的決定 Mock Server 的回傳值之外，還能匯入 Open API/Swagger，於是我把我手上收集的 Mock Server 清單玩了一遍，發現這一套 Mock Server 可以滿足我需要的
Specflow 的 table 預設用來處理單一欄位，若是想要在欄位裡面塞入 json 或者是比對 json 就得自行處理，這裡列出我常用的方式。
在測試時，TestContainers 它可以簡化我們產生 Container 的步驟，配置 Container 的方式也相當的簡單、明確；從同事得知 TestContainers，周末則來研究一下使用方式。
當 SpecFlow 的測試步驟需要依賴其他物件時，SpecFlow 支援 Context Dependency Injection，只要在 Step 的建構函數開洞，SpecFlow 就會自動幫你注入
NBomber 是一個將自身定位為獨立於協議的輕量型的壓力測試套件，使用 F# 中開發的，測試可以用 F# 和 C# 編寫。它是真的開 C# 專案編寫負載測試，JMeter 和 K6 都是編譯好的二進位檔，寫測試時，需要使用他們規定的腳本語言；如果你是 C# 開發者，NBomber 就能夠很輕鬆的客製化你想要的功能
JMeter 是我目前正在使用的壓力測試工具，支援 GUI、CLI，配置容易，也能自動化，網路上的教學資源也相當的豐富，在這裡我將分享我常用的配置，希望對你有幫助
K6 是一套用 JavaScript 編寫測試腳本的工具，對於前端的開發夥伴可是相當的友善，Jetbrains IDE 也有整合它，在開發/測試體驗上肯定有一定的水準，為此深得我心，於是便快速的調查一番，紀錄使用心得
當你的服務需要隱藏真實的訊息給調用端時，除了在每一個 Action 各自處理，Middleware 也是選擇之一，本想這應該是很簡單的操作，沒想到碰了一鼻子灰，以下是我複寫 HttpContext.Response.Body 的步驟，希望對正觀看的你有幫助。
在 ASP.NET Core 的整合測試我們可以使用 WebApplicationFactory、TestServer，這我前面幾篇已經提過了需要的可以參考之前的文章 WebApplicationFactory、TestServer。Middleware 用上述的步驟肯定是沒有問題的，但是需要的環境、步驟也比較多，可能還會因為其他 Middleware 順序所帶來的影響，今天我還要分享 ASP.NET Core內建 Mock HttpContext 做法，讓我們可以快速的針對某一個 Middleware 進行單元測試
Allure TestOp 是一套可以將測試結果產生成漂亮的測試報表，支援很多測試框架和 Cucumber/Gherkin 語言，我將專注在 .NET，接著，就來動手實作吧。
