靜態元素 (Static Elements) 的單元測試, 以 System.IO.File.ReadAllText 為例

Unit Test for Static Elements (System.IO.File.ReadAllText) in ASP.NET Core 6 MVC

前言

接續前一篇 樂透開獎(含日期限制) 的例子, 假設有一個新的需求: "樂透開奬有一個前置作業, 必須由主辦人員按下[開始]按鈕, 才能開獎".

本文假設主辦人員按下[開始]按鈕, 會在主機端產生一個檔案 (Extras/startup.txt), 內含主辦人員的姓名.

因此, 程式要增加一個讀取檔案內容的動作.

• 若可讀到 Extras/startup.txt, 才可開獎, 並回傳開獎的結果, 要再加上主辦人員的姓名.
• 若讀不到 Extras/startup.txt, 則不可開獎, 並回傳警告訊息.
  • "", -2, "主辦人員尚未按下[開始]按鈕". // 第1個空字串, 代表主辦人員的姓名

這裡很單純的想法, 是用 File.ReadAllText() 的方法, 因為是 static class + static method, 應該要如何建立測試呢?

以下係採 參考文件1..及2.. 方式進行演練及實作.

完整範例可由 GitHub 下載.

靜態元素 (Static Elements) 的單元測試, 以 DateTime.Now 為例

Unit Test for Static Elements (DateTime.Now) in ASP.NET Core 6 MVC

前言

接續前一篇 樂透開獎 的例子, 假設有一個新的需求: "樂透開奬不是每天開, 而是固定每個月的 5 日才會開獎".

因此, 程式要加一個當前日期時間的判斷.

• 若為 5 日才可開獎, 並回傳開獎的結果.
• 若為其它日期, 就不可開獎, 並回傳警告訊息.
  這個邏輯要如何測試呢? 總不能等到每個月 5 日, 或者調整筆電的系統時間, 才來測試吧.

以下係採 參考文件2.. "An interface that wraps the DateTime.Now" 方式進行演練及實作.

完整範例可由 GitHub 下載.

非決定性元素 (Non-Deterministic Elements) 的單元測試, 以亂數 (Random) 為例

Unit Test for Non-Deterministic Elements (Random class) in ASP.NET Core 6 MVC

前言

非決定性元素 (Non-Deterministic Elements) 是指在軟體開發中, 其行為或輸出無法預先確定或不會每次都產生相同結果的元素.
這種不確定性通常是由於外部因素, 隨機性, 系統狀態或執行環境的變化所引起.
非決定性元素在測試時可能帶來挑戰, 因為相同的輸入不一定導致相同的輸出.

以下是一些常見的非決定性元素範例:

• 隨機數生成 (如 Random 類別): 隨機數生成器產生的數字是不可預測的, 每次調用可能得到不同的結果.
• GUID 生成 (如 Guid.NewGuid()) : 全局唯一標識符 (GUID) 生成器每次調用時都會產生一個唯一的值.
• 當前日期和時間 (如 DateTime.Now) : 當前的日期和時間在每次調用時都會不同, 這取決於當前的系統時間.

在單元測試中處理非決定性元素時, 一個常用的策略是通過封裝 (Wrapping) 這些元素於可控的介面後, 使用模擬或替身物件 (Test Doubles) 來提供可預測的輸出. 這樣可以減少測試的不確定性, 並提高測試的可靠性和重複性.

以下茲以一個 ASP.NET Core 6 MVC 的專案, 以 Random 類別為例, 進行演練.

完整範例可由 GitHub 下載.

[SQL Server] T-SQL 測試輔助工具或方案 (3) : tSQLt + SSDT

前言

接續前兩篇 (第1篇, 第2篇) 對於 T-SQL 測試輔助工具或方案 的說明. 

因筆者日前看到了 2 篇整合 tSQLt + SSDT 的文章, 看來可以利用 Visual Studio 進行版本控管, 及團隊協同合作; 比單純在 SSMS 進行開發, 有更大的優勢.

茲以下段落進行說明.

1.. 建立資料庫

2.. 建立 Table / View  / Production Code

3.. 在 Visual Studio 建立第 1 個資料庫專案 (MyDemo), 並匯入 SQL Server 資料庫

4.. 在 Visual Studio 建立第 2 個資料庫專案 (MyDemo_Tests), 用以存放 tSQLt 相關程式 及 測試程式碼 (Test Code)

5.. 加入測試程式碼 (Test Code)

6.. 部署及測試

7.. 結論

8.. 延伸閱讀 (2018.07.04)

9.. 參考文件

[SQL Server] T-SQL 測試輔助工具或方案 (1) : tSQLt

前言

最近工作上, 可能會需要寫 stored procedure, 想說找一下有沒有測試輔助工具或方案, 以提昇 stored procedure 的品質, 避免後續維護時, 出現改東壞西的狀況. 

筆者以免費的工具或解決方案為優先, 找到的第1個方案是 tSQLt. 至於要付費的, 如參考文件 5.., 筆者還沒有時間去試用.

tSQLt 是一套 Open Source 的 Unit Test Framework; 可以協助 SQL Server 開發人員, 直接在 SQL Server 上進行測試.

所謂測試, 是指實際執行值, 與預期值是否相符的驗證. 基本上分為功能性 (單元測試, 整合測試, 使用者測試) 與非功能 (效能測試, 壓力測試). 

以下僅就單元測試與整合測試, 用易於瞭解的描述作說明. 至於嚴謹的定義, 可以參考 91哥的系列文章: [30天快速上手TDD]目錄與附錄. 筆者在測試的部份, 深受 91哥 "自動測試與 TDD 實務開發(使用C#)" 課程的影響.