iT邦幫忙

2022 iThome 鐵人賽

DAY 21
0

上回我們建立了多組Case的單元測試,假設我們現在對於我們的方法都充滿信心,那當我們API在使用這些方法時,因為過程中可能包含了複雜的計算、判斷以及組入,所以在這邊我會著重在輸入的參數以及得到的結果,今天來嘗試建立一個回傳物件的API以及我對這支API的整合測試。


首先我們先建立API要回傳的物件,如下:

    public class Product
    {
        public int ProductID { get; set; }

        public string Name { get; set; }

        public decimal Price { get; set; }

        public string Category { get; set; }

        public bool IsSale { get; set; }
    }

假設我們有一隻API是要根據輸入的價錢以及分類取出商品清單,當然裡面會做一些處理,我們假裝它是經過複雜的方法得來的,語法如下:

        public List<Product> GetProductList(decimal price, string category)
        {
            //假設這些物件是從資料庫取出要進行處理
            List<Product> products = new List<Product>()
            {
                new Product() {
                    ProductID=1,
                    Name ="吹風機",
                    Price=100,
                    Category = "電器"
                    ,IsSale=true},
                new Product() {ProductID=2,
                    Name ="電風扇",
                    Price=80,
                    Category = "電器",
                    IsSale=false}
            };

            var result = products.Where(x => x.Price <= price &&
            x.Category == category &&
            x.IsSale == true).ToList();

            return result;
        }
    }

從API取得物件清單的邏輯為不高於設定價錢、要指定分類、要有販售,不過當我們要做測試的時候,我們想針對整個物件內容作測試,假設我的Price輸入100,Category輸入"電器",我能預期我的商品清單中只會有一個物件,預期結果如下:

            List<Product> products = new List<Product>()
            {
                new Product() {
                    ProductID=1,
                    Name ="吹風機",
                    Price=100,
                    Category = "電器"
                    ,IsSale=true}
            };

而我們測試Case要比對裡面的內容,當然測試如何建立Assert沒有一定規則,但基本上總要對物件的內容作驗證,測試Case語法如下:

        [Theory]
        [InlineData(100, "電器")]
        public void TestCase(decimal price, string category)
        {
            var actual = GetProductList(price, category);

            List<Product> expected = new List<Product>()
            {
                new Product() {
                    ProductID=1,
                    Name ="吹風機",
                    Price=100,
                    Category = "電器"
                    ,IsSale=true},
            };

            Assert.Equal(expected.Count(), actual.Count());
            Assert.Equal(expected[0].ProductID, actual[0].ProductID);
            Assert.Equal(expected[0].Name, actual[0].Name);
            Assert.Equal(expected[0].Price, actual[0].Price);
            Assert.Equal(expected[0].Category, actual[0].Category);
            Assert.Equal(expected[0].IsSale, actual[0].IsSale);
        }

由此可見,這樣測試有助於讓API的預期結果更加的嚴謹,不過在撰寫的流程上來說非常麻煩,甚至如果商品清單有很多個時,我們會在測試這個API會變得很麻煩,後續我們再來想想如何讓整個流程更加流暢,也讓整個測試流程比較合乎邏輯。

更多小知識,我們下次見~~


上一篇
DAY 20 :單元測試執行多筆測試Case
下一篇
DAY 22 :使用FluentAssertions提升測試Case可讀性及便利性
系列文
沒有厲害的頭腦,也能利用腳本實現懶人寫程式的夢想30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言