天天看點

GitHub 的 Action 接入 Stryker.NET 進行自動化測試單元測試魯棒性

假設有一個搗蛋的小夥伴加入了你的團隊,這個搗蛋的小夥伴喜歡亂改代碼,請問此時的單元測試能否攔住這些逗比行為?如果不能攔住逗比行為,是否代表着單元測試有所欠缺,或者有某些分支邏輯沒有考慮到。本文将告訴大家的 Stryker.NET 就屬于這樣的一個搗蛋的小夥伴,這個工具将會在執行測試的時候亂改你的代碼,看看你的單元測試是否能攔住這樣的行為。如果在亂改代碼之後,單元測試依然是通過的,那證明單元測試沒有攔住此行為,說不定就需要改改單元測試了

大家都知道 GitHub 的 Action 可以非常友善将 dotnet tool 加入到工具鍊中,剛好 Stryker.NET 也是通過 dotnet tool 釋出的,是以在 GitHub 的 Action 上接入十分簡單

在 GitHub 的 Action 用上 Stryker.NET 就可以自動測試一下自己編寫的單元測試的魯棒性,看看單元測試是否能幫忙攔下一些不符合預期的行為變更。因為在開源項目中,單元測試很重要的一點在于,協助新加入的開發者了解自己編寫的代碼是否能在此開源項目中工作,可以認為新加入的開發者寫的代碼都是在亂改的情況下,單元測試能否幫忙攔下不符合預期的更改。如果不能攔下,那就是單元測試寫的不夠

我從張隊長的部落格看到了 .NET測試用例寫的好不好?讓變種來測試一下 這篇部落格,了解到了 Stryker.NET 這個神奇的工具,于是在我的 AsyncWorkerCollection: 高性能的多線程異步工具庫 中接入。本文接下來也使用此項目作為例子來告訴大家如何在 GitHub 的 Action 接入

開始之前,先聊一下 Stryker.NET 的原理,其實做法很簡單,就是對現有的項目代碼進行瞎改,例如将判斷相等修改為判斷不相等,在修改之後,再次執行單元測試,看看單元測試能否通過。如果單元測試依然通過,那證明單元測試沒有考慮到此更改的行為。例如原先一個業務是需要判斷相等的,但是被修改為判斷不相等,此時單元測試居然還能過,那就證明單元測試沒有考慮到從判斷相等被改為判斷不相等的行為

能被 Stryker.NET 更改的内容有很多,可以從 https://stryker-mutator.io/docs/stryker-net/Mutators 找到完全的功能。例如将加法修改為減法,将大于判斷修改為小于判斷,将字元串修改為空字元串等等

在開始接入 GitHub 的 Action 之前,先在自己本地測試一下

使用 AsyncWorkerCollection: 高性能的多線程異步工具庫 作為例子,先進入單元測試所有的檔案夾

按照慣例,使用 dotnet tool 的第一步就是安裝工具,請使用如下代碼進行安裝

接着執行如下指令,讓 Stryker.NET 自動測試

以上的核心指令就是 <code>-p="AsyncWorkerCollection.csproj"</code> 用來告訴 Stryker.NET 可以進行亂改代碼的項目是哪個。執行上面代碼之後,将會讓 Stryker.NET 進行對 AsyncWorkerCollection.csproj 項目裡面的代碼亂改,在修改了代碼之後,執行目前的單元測試,看看單元測試能否通過。如果單元測試不能通過了,那證明單元測試寫的不錯。大概的執行的輸出如下

以上代碼證明亂改的代碼上,有 8 個亂改的代碼被單元測試攔住,也就是被單元測試殺掉。而有 145 個亂改的代碼能通過單元測試,證明單元測試其實和沒有的差不多。剩下 5 個是在亂改之後單元測試逾時了

接入到 GitHub 的 Action 也非常簡單,隻需要在 <code>.github\workflows</code> 檔案夾裡面再建立一個叫 stryker.yml 的檔案即可。打開 stryker.yml 檔案,添加自動測試的代碼

步驟十分簡單,首先是隻有在推送到 master 的時候才執行

接着是将代碼拉下

然後安裝工具和執行測試

将此檔案推送到 GitHub 上,合入 master 即可

詳細更改請參考 https://github.com/dotnet-campus/AsyncWorkerCollection/pull/60

GitHub 的 Action 接入 Stryker.NET 進行自動化測試單元測試魯棒性

本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協定進行許可。歡迎轉載、使用、重新釋出,但務必保留文章署名林德熙不得用于商業目的,基于本文修改後的作品務必以相同的許可釋出。如有任何疑問