情境是這樣的：目前開發一個 API 其角色為對 DB 做 Access (CRUD) 的一個界面。

資料流：資料進到 controller，再呼叫 CRUD 函式將資料寫入或讀出 Database。

因為許多運算都是在 SQL 中(PostgreSQL)實現，所以目前使用 Integration testing，可以說是在測試 SQL 是否如預期的邏輯來執行，因此需要將 DB 服務開啟，真實的寫入與讀出 DB。

1. 若為 CUD，則直接在 test function 內定義資料並 call API，並查看 API 執行成功時回傳的資料是否與傳入的資料一致。
2. 若為 R，則需要在 call API 之前先建立情境(代號為 Data1)，例如先插入幾筆訂單，然後 call API 將對應的資料撈出(代號為 Data2)，再比對 Data1 與 Data2 是否相同。

個人在測試 R 時遇到一些疑惑點

1. 建立情境是每個 testing 都要各自建立自己的情境，還是會讓所有 testing 都是一樣的情境？目前個人是在 setup 階段時統一建立情境，在 testing function 中取得 DB 所有資料，再做測試。例如

   def test_ordelist(test_app, db_data):
       def ground_truth(orders):
           blablabla... # 做一些運算將 orders 過濾或轉換為想要的格式
       orders = db_data["order"] # 每個 test 的 db_data 都一樣
       response = test_app.get("/order/")
       response_dict = response.json()
       assert response.status_code == 200
       assert response_dict == ground_truth(orders)
       # 等同於 assert Data2 == Data1
   

2. 這樣的寫法就好像是我使用另一種方法去拼湊出資料，然後測試是否與 SQL 結果一樣。但我看的 testing 案例都是給 literal value，好像沒有見過使用運算後的結果(ground_truth(orders))去當預期的輸出，不知道這樣的測試架構是不是各位有經驗的前輩所樂見的，或者可以提供更好的方向給我 QQ。

3. 為何不用 literal value？是因為 Read 出來的資料都很冗長，我認為若在 test function 中寫出來所有 literal value 會變成不可讀，很難維護。但若前輩們有其他意見可以一起討論！