我已經繼承了一個項目，該項目將通過另一個開發人員編寫的SOAP服務連接到CRM系統。我的問題是：我應該用什麼級別測試與Soap服務的接口？測試API時 - 我應該測試API方法驗證嗎？
我設置了一個測試用例，並編寫了一些方法來測試Soap更新方法，並通過合適的錯誤代碼來確認失敗的客戶或訂單號。
我接下來測試了一個無效的訂單狀態值（不在一組期望的參數中），並且服務返回了一個不成功的代碼。
我相信我應該向開發人員報告，但現在我應該從測試套件中刪除這個測試嗎？或者讓它表現爲失敗？
如果soap服務選擇不驗證其輸入參數我認爲這是一個糟糕的設計，但它不是我的代碼中的錯誤，我只需要確保在將值傳遞給其他系統之前清理輸入，並且無論如何，驗證應該覆蓋另一組測試。
我是否應該首先通過單元測試與SOAP服務進行交流？
如果庫（或第三方代碼）具有良好的聲譽（例如，Apache Commons，Guava ...），則不會重新測試該API。但是，當我不確定代碼的質量時，我傾向於編寫幾個測試來驗證我對庫/ API的假設（但我不重新測試所有庫）。
如果這些簡單的假設失敗，這對我來說是一個非常糟糕的跡象。在這種情況下，我傾向於編寫更多測試來檢查庫的更多方面。在你的情況下，我會寫更多的測試和向開發者發出錯誤信號。
這些測試不會丟失，因爲如果提供了新版本的庫，您仍然可以使用它們來檢查迴歸。
您應該爲每個原子功能要求編寫至少一個測試。現在，如果您使用最少的接口指南編寫代碼，那麼每個原子功能需求最多隻能有一個接口。但是你可以爲每個需求編寫多個測試，因爲可能有多種可以測試的不變量。
一般來說，編寫測試時應考慮不變量和功能要求，而不是接口方法。測試> =原子功能要求。
想想服務「契約」，先決條件（即合法輸入）是什麼，它是後置條件（即合法輸出）和不變量（合法服務狀態）。如果開發人員不清楚這些信息，或者有其他開發人員濫用該服務的可能性，則應該對其進行報告和處理。
雖然有一個例外 - 理論上這些都很好，但如果沒有其他客戶服務（除了最初的開發人員），有時候多餘的檢查已經過時。假設在這種情況下，通過客戶代碼檢查並消除無效輸入是非常合理的。
謝謝 - 因此，如果沒有對實際API進行專門的單元測試，您應該保留此特定測試（不應在預期集合中的參數應該被拒絕），直到其他開發人員修復其代碼？ –
@ user903182是的。在Java中，可以使用@ Ignore註釋測試。彙編只是跳過它們。您可以稍後在交付新版本庫時重新激活它們。事實上，你甚至可以將這些測試發送給開發人員。他/她應該將它們包含在他/她自己的測試集中。 – JVerstry