如何使用這份公開 API 清單
挑一個 API、挑一項技能，然後寫三個案例：正常流程、一個邊界情況，以及一個你預期會失敗、並且要斷言失敗形式正確的案例。第三種正是大多數人會略過的，也正是「抓得到 bug 的測試套件」和「只能確認服務還活著的測試套件」之間的差別。
開始之前先提醒一句。這些都是由志工維護、或由企業基於善意提供的共用服務。請控制呼叫量，不要拿負載產生器對著它們打，能快取回應的地方就快取。
適合學習請求與回應的基礎
JSONPlaceholder。 一個假的 REST API，提供貼文、留言、使用者與待辦事項。它接受寫入請求，但只是假裝有把資料存下來。 練習： CRUD 動詞、狀態碼，以及「請求成功」和「變更真的寫進去」之間的差別。正因為寫入其實不會被保存，它反而格外適合用來學會對結果斷言，而不是只對回應斷言。
HTTPBin。 一個會把你送出的內容原封不動回傳的端點，另外還有一些路由可以回傳你指定的任何狀態碼、刻意延遲，或回傳格式錯誤的內容。 練習： 逾時、重試、重新導向處理，以及標頭行為。想看看你的測試套件遇到 503 會怎麼反應，隨時都能自己製造一個出來。
REST Countries。 國家資料，結構穩定、文件完整，而且不需要金鑰。 練習： 在一份夠大、足以有看頭，又小到可以一眼讀完的回應內容上，練習 schema 斷言與欄位層級的驗證。
適合練習分頁與大型集合
PokéAPI
一份龐大、彼此層層連結的資料集，採用標準的 offset 與 limit 分頁方式。
練習： 逐頁走訪、斷言完整走完一輪拿到的筆數與集合宣稱的總數一致，以及抓出分頁邊界上的差一錯誤。
Open Library
書籍與作者資料，附帶搜尋功能，而且有大量欄位缺漏或不一致的資料。
練習： 容忍選填欄位。真實資料本來就很亂，一套假設每筆資料都完整的測試，一碰到正式環境就會壞掉。
GitHub REST API
在低流量下不帶驗證就能用，也可以用 token 通過驗證後使用。
練習： 以 link 標頭做分頁、條件式請求，以及通過驗證前後行為上的差異。
適合練習身分驗證與速率限制
GitHub，帶驗證
練習： token 的處理、權限範圍錯誤，以及斷言沒有權限的請求會以正確的方式失敗，而不是籠統地失敗。
Open-Meteo
天氣預報，不需金鑰，並且公開了合理使用政策。
練習： 查詢參數的各種組合，以及正確答案會隨每次執行而改變的時間性資料。很適合用來訓練那些無法精確比對的斷言。
再談 HTTPBin
練習： 在專為此打造的端點上練習 basic auth 與 bearer token 流程，不必冒著消耗別人配額的風險。
任何公開 API 都值得練的三種斷言
不論你挑的是哪個服務，以下這些習慣都能直接帶到你自己的 API 上。
斷言回應內容，而不只是狀態碼。 該有資料卻回傳空清單的 200，是個只看狀態碼的斷言會欣然放行的 bug。光是養成這一個習慣，抓到的真實缺陷就比其他任何做法都多。
斷言失敗要以正確的方式失敗。 去請求一個不存在的東西，檢查你拿到的是正確的狀態碼，以及一個能用的錯誤結構。回傳 200、卻把錯誤物件包在裡面的服務很常見，不知道這件事的測試套件會永遠報綠燈。
斷言資料之間的關聯，不只是單一欄位。 如果一篇貼文引用了某個使用者，就去取得那位使用者、確認確實存在。大多數值得一抓的 bug 都躲在兩個端點之間，而不是單一端點裡面。
把代理程式指向其中一個 API
如果你想先看看自動產生的測試覆蓋長什麼樣子，再決定要不要用在自己的服務上，公開 API 是個安全的練習場。沒有資料會被汙染，也沒有環境會被弄壞。
把專案指向基底 URL，讓探索流程列出所有端點，然後在執行任何東西之前，先讀一遍產生出來的計畫。計畫本身才是重點。過程中有兩件事值得留意。
它會擷取值，而不是把值寫死嗎？ 建立資源的呼叫會回傳一個識別碼，下一次呼叫就該用它。識別碼寫死，正是測試套件只跑得起來一次的常見原因。
它會把有相依關係的呼叫排出正確順序嗎？ 你不可能去取得一篇從未建立過的貼文底下的留言。看看計畫是不是理解這一點，還是只把端點照字母順序排一排。
接著就執行它，然後把失敗的地方讀過一遍。在公開 API 上，大多數失敗來自你的假設，而不是服務本身——這正是要學的那一課。
如果你比較想自己掌握測試程式碼，CLI 在後端測試上走的是另一條路：你用 Python 自己寫呼叫與斷言，宣告每個測試需要什麼、產出什麼，並把清理工作標記成獨立的測試。這樣前期要花的工夫比較多，而且測試套件會留在你自己的儲存庫裡——有些團隊要的正是這個，有些團隊則不然。
從練習走向你自己的服務
在公開 API 上練習和測試自己的服務，中間的落差比看起來大；先知道難度在哪裡陡升，可以少受一些挫折。
從你的角度來看，公開 API 是無狀態的：你只是讀取，而你寫進去的東西不是沒被保存，就是無關緊要。你自己的服務正好相反。當你開始測試真實的東西，你就同時接手了會過期的驗證、必須先存在才能建立其他資料的資料、只在執行期間才存在的值，以及自己收拾善後的責任。
這些在教學文章裡一個都不會出現，卻在上工第一週全部出現。所以請把公開 API 這個階段當成在學斷言——這部分可以完整帶著走——並且預期狀態的處理是之後要另外學的一件事，而不是同一項技能的延伸。
這些 API 不該拿來做的事
不要拿它們做負載測試。它們是免費的、共用的，而且帳單有人在付。
不要讓正式環境依賴其中任何一個。使用條款會變、專案會被封存，志工也會累。
不要把「對 JSONPlaceholder 全數通過的測試套件」當成你自己的 API 正確無誤的證據。它只說明你的測試設定沒問題——這確實很有用，但這個主張小得多。
在真實服務上試試看
等到斷言的習慣養成得差不多了，往自己的 API 跨出去的那一步，正是狀態問題開始出現的地方，而這一塊就是 TestSprite 以產品形式處理掉的部分。Auto-Authentication 讓工作階段在整輪執行中保持有效。Dynamic Variables 把建立資源時拿到的識別碼帶進刪除的呼叫裡。Dependency Chains 會推算出什麼必須先發生。Auto-Cleanup 則會清掉這輪執行建立出來的東西。
在自己的服務上起步，流程和上面那段公開 API 的練習很像：把專案指向基底 URL，讓探索流程列出端點，並在任何測試執行之前先讀過產生出來的計畫。差別在於，這時候的計畫會涵蓋授權與邊界情況，而且整輪跑完不會留下任何殘留。
先拿公開 API 來試是件安全的事，因為沒有資料會被汙染；而且比起執行結果，那份計畫更能讓你看清這個工具。
我該從哪一個開始？
第一個小時用 JSONPlaceholder，因為怎麼弄都不會出事。接著換 HTTPBin，因為它讓你可以刻意製造失敗，而拿失敗來練習正是學習發生的地方。
這些之中有哪些需要 API 金鑰嗎？
清單上大部分都不需要。GitHub 在低流量下不帶驗證也能用，而去申請一個 token 之所以值得，正是因為它讓你有機會練習帶驗證的流程。
我可以把這些用在 CI 流程裡嗎？
如果只是教學性質的小型測試套件，可以。但只要是每次提交都會跑的東西，就改成對本機的模擬服務執行。把 CI 指向志工營運的服務，正是好用的免費資源不再免費的原因。
這和一份公開 API 的 Postman 集合有什麼不同？
集合給你的是一堆現成的請求。這份清單則是圍繞著每個服務能教會你什麼來編排；當目標是把測試做得更好，而不只是讓某一次呼叫成功時，這一點更重要。
最快看到自動產生的測試覆蓋的方法是什麼？
把專案指向一個公開的基底 URL，讓探索流程列出端點，並在執行任何東西之前先讀過計畫。比起執行結果，計畫更能讓你看清這個工具。