測試策略：斷言響應的「特徵」或斷言全響應？

Question

我與同事發生了「哲學」分歧，我想聽到社區對雙方的想法（或更好的第三種選擇）。

基本上我們有一個返回好友列表的JSON API。結果看起來像這樣：

[{"name":"Bob", "uid":12345, "level":4}, {"name":"George", "uid":23456, "level":6}] 

有一個正常的「共同的朋友」要求的地方，影響響應。

的分歧基本上結束了，這是更好，

• 測試，關於響應的 「特徵」 斷言：

  def test_results_are_sorted_by_name(): 
      .. <setup 2 friends> .. 
  
      response = controller.getFriendsList() 
      assertLessThan(response[0].name, response[1].name) 
  
  def test_blocked_users_are_not_returned(): 
      .. <setup some friends and block one, storing the id in blocked_uid> .. 
  
      response = controller.getFriendsList() 
      for friend in response: 
       assertNotEqual(friend.uid, blocked_uid) 
  

• 測試其上的文字響應斷言

  def test_results_are_sorted_by_name(): 
      .. <setup 2 friends> .. 
  
      response = controller.getFriendsList() 
      expectedResponse = {...} 
      assertEqual(response, expectedResponse) 
  
  def test_blocked_users_are_not_returned(): 
      .. <setup some friends and block one, storing the id in blocked_uid> .. 
  
      response = controller.getFriendsList() 
      expectedResponse = {...} 
      assertEqual(response, expectedResponse) 
  

哪個更好，爲什麼？

是否有其他選擇比兩者都好？

Answer 1

純意見相左，但：

測試文字鼓勵不好的行爲 - 字面測試是如此脆弱，如此頻繁，人們學習如何去應對通過更新字面測試失敗打破。即使他們破壞了它們，他們也可能說服自己是正確的，更新文字，然後繼續前進，無意中通過測試鞏固了一個錯誤，確保它不會被修復。

功能測試是正確的選擇。有些方法可能會出錯 - 您可以輕鬆編寫功能測試，看起來正確，但即使代碼已損壞也可以通過 - 但最好的解決方案是也使用功能測試的集成測試，以確保服務實際上做你期望的事情。

Answer 2

您需要根據功能進行測試，而不是文字迴應。

原則上，這允許人們以不破壞已經寫好測試的格式來改變格式（添加字段等）。當他們這樣做時，你的測試不會中斷，這是他們應該做的。 （如果添加新字段不好，請爲此寫一個測試。）

實際上，字面文本測試有時會通過粘貼新字符串而得到修復，真正的問題會在沒有任何人的情況下被粘貼給他們足夠的想法。

如果您想確保響應不會通過測試而以某種方式更改，但不適用於數據收件人，請包括一些基本級別的集成測試。