[Unit Test]Hello Unit Test

我從不排斥寫單元測試,因為單元測試確實對多人開發的專案或產品太重要了,

但我絕對不會為了寫單元測試而寫單元測試,也不會每一個功能都寫單元測試。

由於我個人都把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(),可以發現程式邏輯寫成相減而非相乘,

修改後再次執行測試,我們就得到一個綠燈了。