此篇文章主要帶大家利用手邊工具將測試視覺化，有興趣就往下看吧！

稍微回顧前一篇，我們已經有了測試程式，但目前只能知道程式碼有測試過，實際上沒有一個依據可以判斷哪邊的程式碼很冗，除非你的 IDE 強大到能告訴你，不然用肉眼看還真的蠻困難的...

那測試視覺化是要看什麼東西啊？以我們這邊的案例就是看測試涵蓋率！

所以這邊會介紹手邊幾樣工具，來幫助你將測試視覺化～

觀文前叮嚀：

1. 此篇文章主要以 .NET 為主，其它語言應該不會差太多！
2. 因上一篇是用 NUnit 寫測試，但後來在公司 Jenkins 環境踩到太多雷，要不是環境不支援，就是撞牆撞到不行，所以此篇文章改以 MSTest 為測試框架！（測試框架的替換並不困難，你需要了解的是名稱差異及執行測試的生命週期轉換...等等）

SonarQube

其實 SonarQube 不單單只有程式碼品質掃描，如果設定有正確，也能看到測試涵蓋率哦！那怎麼做？

1. 建立好專案 Repository 

總得要有個 Repository 吧，不然要怎麼掃 XD？

.NET Core 範例

.NET Framework 範例

2. 透過 Jenkins 建立程式碼品質掃描（SonarQube）的 Job

Job 的設定可以參考 WebGoat.NET...等等。

.NET Core 範例

.NET Framework 範例

3. 進入 SonarQube Dashboard 並初步分析報告

先點選 Overall Code 頁籤且頁面往下拉。

已經可以看到測試涵蓋率了，但我好奇的是為什麼只有 95 %？

看起來是 Program.cs 沒測試完整...

還記得 Program.cs 我是寫整合測試嗎？因為它是一個 Console App，所以可以透過 Shell 來執行，而當初我寫的邏輯是需要有參數才能執行輸出！

所以從中可以得知一件事，就是我並沒有對無參數時的執行結果寫下測試案例，那這個案例要不要補呢？

我會覺得這要看你，怎麼說呢？

先假設無參數情況有兩種可能：

1. 真的不需要執行任何輸出，那你可以不用補，因為你沒得驗證，沒有任何依據...

2. 一定要輸出某些字串，那我就會建議要補，畢竟有得驗證...

而我這邊的案例比較偏向第 1 點，所以我是沒打算去補，但你可能會問提高涵蓋率不好嗎？

不是不好，只是到底有沒有必要？一般來說要把現有的系統寫到涵蓋率有 70% ~ 80% 以上，應該就蠻厲害了，這表示你對你設計的系統有一定掌握程度...

理想上涵蓋率接近 100% 一定是比較好，但很多系統一開始就走歪了，突然有天你想盡各種辦法終於拉到接近 100%，卻反而沒有比一開始沒走歪的系統要好維護，那何必呢？循序漸進提升才是比較好的選擇...

說太多了，先回過頭來看看程式碼旁邊的線各代表什麼意思吧！

 表示此行程式碼有涵蓋到。

表示此行程式碼有部分涵蓋到。

 滑鼠移過去線上會有一些訊息能看。

還有一種是灰色，不過倒是跟涵蓋率比較無關，是屬於重複程式碼區塊的部分，它會告訴你哪幾行跟哪幾行有重複。

整合 GitLab Webhook 來觸發建置並執行程式碼品質掃描

都已經 1202 年了，還要手動點建置？NoNoNoNoNoNoNoNoNoNo！

1. 修改 Jenkins Job 組態，建置觸發程序有一個 Build when a change is pushed to GitLab. 選項勾起來

有個 Webhook URL 要記一下，等等會用到，其它的設定跟怎麼觸發建置有關係，依照你的狀況即可。

2. 接著點開進階，可以過濾分支及產生 Secret token

點 Generate 產生一組 Secret token 要記一下，等等會用到。

3. 回到專案 Repository 點選 Settings > Webhooks

把剛剛得知的 Webhook URL 和 Secret token 填下並新增。

4. 測試觸發

可以主動觸發來測試。

這時回去 Job 看就會發現已經在建置中了！超棒der！

透過 GitLab Webhook 就可以不用再手動點建置了，那可能又有人會問怎麼不用 GitLab CI/CD（如同 GitHub Action）？

其實也不是不行啦，只是如果要用 GitLab CI/CD，你可能需要額外準備一些環境來做這件事，另外還要寫 YAML 檔出來告訴它管線應該怎麼跑...

如果未來有使用到，會再分享給各位知道，不過公司一堆 CI/CD 大神，應該也不用我出來講了 XD...

不過我倒是有 GitHub Action 的範例可以給各位參考，實作概念大概如下幾步：

1. dotnet restore
2. dotnet build
3. dotnet test
4. Repository 公開程度
   • Public：Codecov、Coveralls...等等選擇比較多（通常能在網頁看到視覺化結果）。
   • Private：ReportGenerator-GitHub-Action 搭配 Upload a Build Artifact （需要自己下載來看）。
5. 看報告

Local

但不知道各位有沒有想過一個問題？就是我每次看報告都要等 SonarQube 跑完才能看，難道就沒辦法在本地端看到這些程式碼涵蓋比例嗎？NoNoNoNoNoNoNoNoNoNo！

有些 IDE（Visual Studio Enterprise、Rider...等等），基本上有花錢的情況下，它們其實都有內建可以在 CodeBase 直接看到涵蓋程式碼比例，甚至是 % 數都能知道！

但多數人以前也沒有寫測試的習慣，所以這功能也用不太到，但隨著寫測試的人越來越多的情況下，這些功能就很重要了！

可以預防你寫出很冗的程式碼，這還不重要嗎 XD？

那假設今天你沒有那些酷酷的 IDE 該怎麼辦呢？那就只能祈禱有好心人開發 IDE 套件來幫助你了...

很剛好的還真的有人開發出來，而且還持續再維護，至少我看 Visual Studio 2022 還有...

接下來會演示 Visual Studio Community 搭配 Fine Code Coverage 套件，呈現類似於 Visual Studio Enterprise 在 CodeBase 看到的涵蓋程式碼比例！

Visual Studio Community with Fine Code Coverage

1. 準備好 IDE（除了 Enterprise 版本以外都可，若已有酷酷的 IDE 就不用往下看了...）

先附上人權，避免有人以為我有酷酷的 IDE。

2. 搜尋 Fine Code Coverage Visual Studio 擴充套件

3. 先看看我們原本 CodeBase 的樣子

恩...就是 CodeBase。

4. 嘗試執行測試

5. 回過頭看看現在 CodeBase 的樣子

你最好別跟我說跟之前的一樣哦 ^_^

此時你會看到 CodeBase 旁邊有一些顏色的線，估計你會看到 3 種顏色：

綠色：表示此行程式碼有涵蓋到。

黃色：表示此行程式碼有部分涵蓋到。

紅色：表示此行程式碼沒有涵蓋到。

6. 套件本身也有提供一些參考指標給你看

可以在 IDE 就能看到涵蓋率了！（重跑測試都會更新）

可以了解測試總結！

另外還有一些指標供參考，像是 Cyclomatic complexity、CRAP score、NPath Complexity。

如果程式碼過於複雜它也會提醒你！

總結

1. 了解如何從 SonarQube 分析測試涵蓋率
2. 透過 GitLab Webhook 觸發程式碼品質掃描，達到持續整合的一小塊碎片。
3. 了解如何從弱弱的 IDE 變成稍微酷酷的 IDE（搭配 Fine Code Coverage 於本地端看到測試涵蓋率...等報告）

感謝各位把文看完，若有一些疑問，歡迎指教與補充！

如果未來有遇到更方便更直覺的做法，會在分享給各位知道！