上回我們使用了FluentAssertions來幫助我們提升測試Case的可讀性以及便利性，讓我們在撰寫測試Case的時候可以更專注在各式的預期結果，但是在我們上回的API測試Case中依然有一些問題存在，包括我們把預期結果寫在測試Case中以及測試資料來源需要逐一寫入，所以接下來我們就來嘗試解決這些問題，建立一個簡易的測試骨架。

我們的適用的對象為主要回傳資料的API，在我工作上有些API是屬於排程類的，這類API比較著重在執行的過程中，相對來說，過程的log就相對重要，而結果通常只是true或是false，若測試Case單單只測試API結果是否成功，往往會遺漏掉很多重要的資訊。

首先我們先將上回的測試Case做一些改寫，原測試Case如下：

        [Theory]
        [InlineData(100, "電器")]
        public void TestCase1(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},
            };

            actual.Should().BeEquivalentTo(expected);
        }

我們先將預期結果以參數的方式傳入，這樣有助於我們在修改API或是撰寫其他測試Case時可以不用大幅更動測試Case內容，我預計將整個結構改寫為下方的格式，語法如下：

        [Theory]
        [ClassData(nameof(GetProductList_Scenrio))]
        public void TestCase1(Scenario payload)
        {
            var actual = GetProductList(payload.Price, payload.Category);

            var expected = payload.Expected_GetProductList;

            actual.Should().BeEquivalentTo(expected);
        }

主要的格式為傳入的測試情境以Class取代，並且將所有API使用的參數以及預期結果放在裡面，當然目前若沒對測試情境做改寫是沒辦法使用的，後續我們就繼續一步一步把這些架構弄到位。

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