我從不排斥寫單元測試,因為單元測試確實對多人開發的專案或產品太重要了,
但我絕對不會為了寫單元測試而寫單元測試,也不會每一個功能都寫單元測試。
由於我個人都把business logical寫在SP或function,
一是效能考量,二是面對需求改變我能立即實現,但這種方式最讓人詬病的是,
你沒有寫UnitTest,你如何確認改這支SP不會影響其他SP?
你如何讓後面維護的同事,確認你所有的SP都符合business logical的結果?
你如何實現CI?...等。所以前年我開始針對複雜的SP或function撰寫tSQLt,
雖然無法解決上訴全部問題,但基本也提高SP的可靠度和穩定度,
坦白說,日後修改這些複雜的SP,我只要跑過測試沒問題,
大大降低上code到正式環境的風險,也減少我事前的整合測試時間~~~anyway,
現在就來開始我第一個單元測試吧。
Ps:tSQLt後面有時間我會繼續分享個人實務經驗。
測試目標Calculator
public class Calculator
{
public int FirstNum { get; set; }
public int SecondNum { get; set; }
public int Result { get; set; }
public void Add()
{
this.Result = this.FirstNum + this.SecondNum;
}
public void Multiply()
{
this.Result = this.FirstNum - this.SecondNum;//demo bug
}
}
新增單元測試class
[TestClass]
public class CalculatorTests
{
Calculator calculator = new Calculator();
[TestMethod]
public void TestMultiply()
{
calculator.FirstNum = 20;
calculator.SecondNum = 30;
calculator.Multiply();
Assert.AreEqual(600, calculator.Result);
}
[TestMethod]
public void TestAdd()
{
calculator.FirstNum = 10;
calculator.SecondNum = 15;
calculator.Add();
Assert.AreEqual(25, calculator.Result);
}
}
上面的測試程式很簡單,就是測試目標的Add()和Multiply()這兩個方法結果是否如預期,接下來我們就來執行每個測試。
執行TestAdd
執行TestMultiply
測試失敗,結果應該為600,但實際卻是-10。
回頭看目標Calculator. Multiply(),可以發現程式邏輯寫成相減而非相乘,
修改後再次執行測試,我們就得到一個綠燈了。