[iThome第8屆鐵人賽 16]OpenCover 整合篇
在上篇介紹了OpenCover的基本運作概念和為什麼要使用OpenCover,在這篇將會實際把OpenCover整合到Build Script裡面。
在上篇介紹了OpenCover的基本運作概念和為什麼要使用OpenCover,在這篇將會實際把OpenCover整合到Build Script裡面。
OpenCover是一個.Net Open Source的測試涵蓋率檢測的工具,透過這個Library,可以檢測出,對於整個程式的測試涵蓋率到底有多少 (當然,要注意一個迷失就是,不一定都要100 %的涵蓋率)。
這篇將會先對如何使用OpenCover做一個初步的介紹,在下篇才會把OpenCover實際整合到build script裡面。
我曾經聽過一個笑話,一個人到一家公司面試,面試官問他:「請問你如何保證/保持你的程式碼品質?」
這個年輕人回答:「我...我會在發現bug的時候把問題加班修好」。
其實這個有點悲哀,也說明了為什麼軟體工程師時常需要加班,因為當軟體越寫越複雜的時候,要保持程式的品質是需要一些事情,但是這些事情是什麼?有沒有可能進入到我們日常環境里?
這個就是接下來會介紹的部分,我們如何透過做CI把程式碼品質要做的事情整合進來。
在之前幾篇已經介紹完了.Net常見的三種Test Framework(Xunit,Nunit 和 MSTest)整合方式之後,相信會發現到這三個task有很地方是重複邏輯。
這些重複邏輯我們都是用了copy 和 paste 的方式處理了,但是未來如果要維護這個build script,甚至要把它變成一個常用/通用的script,這種方式是非常不好
所以,就像任何好的工程師會做的事情一樣,我們也要重構我們的Script。
這篇將會介紹重構什麼,和如何重構。
在介紹完Xunit和Nunit測試之後,這篇將要來看最後一個常見的測試Framework,Visual Studio內建的MSTest。
經過一段時間的介紹,相信對於使用psake來建制專案已經沒什麼問題了 - 我們就要開始進入建制的下個階段,也就是測試。
專案建制起來只是基本條件,但是單元測試是否有通過才是保證程式碼品質的一種方式,因此,不跑單元測試更本就不完整。
在接下來幾篇,將會介紹幾個常見的unit test的framework,先從xunit開始。