上回我們建立了多組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會變得很麻煩,後續我們再來想想如何讓整個流程更加流暢,也讓整個測試流程比較合乎邏輯。
更多小知識,我們下次見~~