我已經使用django-rest-framework製作了其餘的API。
我有多個API端點。一些用於創建對象，一些用於列出對象，一些用於獲取對象的計數等。
在我的測試中，我測試每個端點以確保（例如）創建端點只接受POST請求。我測試列表端點以確保它們只接受GET，而不是POST/PUT/PATCH/DELETE。每個端點都對應一個視圖，該視圖具有確定它們允許哪些請求的設置，但測試可確保這些設置正常工作。測試主要聲明返回某個狀態碼。
測試變得非常重複。評論API的測試大約600行。這種測試是必要的，還是有一個簡化的選擇？正在測試REST訪問是否必要/好？
在編寫冗餘測試和爲系統的關鍵區域獲得足夠的代碼覆蓋率之間始終保持良好平衡。由於您的應用中的終端很可能會有很多移動部分（即響應/請求解析，HTTP調用，數據存儲的訪問等），因此您可能會發現太多的測試可能會顯着減慢測試速度套房。
您經常會發現，結合大量標準單元測試（無i/o），少量目標端到端測試就足夠了。 關鍵是要在關鍵代碼覆蓋率和測試套件的穩定性能之間找到健康的平衡點。
上有一個很好的堆棧溢出的話題，在肯特·貝克討論了一個高效的測試套件：
，你正在測試的框架/庫，而不是這屬於測試反模式的類別你自己的代碼。
像這樣的一些測試是值得的，特別是如果你不熟悉框架，並且它們用來驗證你的使用。儘管如此，對它進行徹底的測試會讓你無法花費在測試應用程序代碼上。
如果你真的覺得一個框架或庫不穩定，你仍然想使用它，你最好直接測試它，即分叉項目（假設它是開源的），添加一些測試，並使拉請求。
這也是一個很好的答案 - 我從未想過這件事。希望我能接受兩個答案！ – dcgoss
我偶然發現了這個很酷的庫：django-rest-assured，這似乎需要大量的測試這種REST訪問的鍋爐板。這使得測試該功能變得更加微不足道，甚至值得您花時間。
是的，django-rest-assured特別爲此目的而建造（我是它的作者）。但是，儘管腳手架支持API的完整測試覆蓋率，但隨着項目的發展和成熟，您應該將其降至您的應用程序所需的最小值，以實現測試的簡單性，性能和可維護性。 – ydaniv
太棒了！感謝您的鏈接！ – dcgoss