微服務合同的自動化測試？

Question

假設我們有一個CreditCardService微服務，它依賴於使用JSON進行通信的ThreeDSecureService微服務。

ThreeDSecureService的API（或甚至實施）的微小變化可能會悄悄地破壞CreditCardService（和其他潛在客戶端）。所以，我們希望自動化測試。

我看到兩個有缺陷的方法，並且想知道如何改進。

1. 在ThreeDSecureService.Tests中進行集成測試。

隨附的ThreeDSecureService測試項目可以通過固定的JSON輸入進行集成測試。僞裝任何依賴關係，它可以運行一個完全的輸入調用，確認服務吞下輸入。

這裏的問題是，如果有人未能意識到他們的變化會如何破壞客戶端，他們幾乎可以「修復」測試來匹配他們的變化。

1. CreditCardService.Tests中的集成測試。

客戶端是實際上想要測試有關ThreeDSecureService預期輸入的斷言的人。但是，這需要客戶端解決方案包含ThreeDSecureService項目以及它所依賴的任何項目。這會否定我們從使用微服務中獲得的許多優勢！

我們如何在不破壞我們從使用微服務中獲得的鬆散耦合的情況下從客戶端斷言（維護依賴關係）？

Answer 1

爲避免突破集成，請使用公共合同。例如，RAML。描述特定服務的客戶將獲得並通過的模型，描述操作和參數。在這種情況下，沒有人依賴於特定的服務或實施，雙方都需要測試他們與合同的溝通。

額外的安全措施將發佈您的合同作爲DLL。在這種情況下，服務的消費者會在一分鐘內注意到變化。如果他們有單元測試，他們可能會更早地顯示任何問題。

作爲一個保持分離的主要規則：不要參考實現，而是引用契約。

Answer 2

我希望我能理解你所問的內容，但如果不是這樣，以下內容至少對你的思維有所貢獻。

我理解你的問題的方式是一個非常實用的方法，即「如何組織解決方案和項目，以最大限度地降低開發人員違反服務合同而不理解其對服務消費者的影響的風險？」

在理想的世界中，開發人員不這樣做。如果他們對服務進行了重大更改，他們知道他們已經完成了，而且這是一個新版本。這就是說，我明白你的觀點 - 很高興能有一些抵禦這種人爲錯誤的保護措施，因爲開發人員大多數時間都是完美的。

如果您正在一個環境中工作，您正在創建其他團隊依賴的微服務，反之亦然，那麼就沒有辦法遵循嚴謹和結構化的方法，即適當的治理。一個能夠反映生產的完整測試環境，所有服務都在運行，並且您可以測試您的服務與其所依賴的服務的集成情況，但這並不會造成任何影響。

如果你在控制所有需要彼此通信的服務，那麼（至少在我看來）沒有理由不應該有一個解決方案，即你所有的服務項目都包含在哪裏以及哪裏您的集成測試項目將啓動所需的所有服務，並檢查它們之間的集成是否按預期工作。

除了契約/接口之外，您的個人微服務不應該知道外界的任何信息，您應該有單元測試來獨立地測試每個微服務，嘲笑依賴關係。

如果一個解決方案變得太大，您可以將其分解爲更小的部分，以便爲每個包含該服務及其最近鄰居的服務提供一個解決方案。在你的例子中，這可能是一個包含ThreeDSecureService，CreditCardService和CreditCardService.IntegrationTests（它測試CreditCardService，然後調用ThreeDSecureService）的解決方案。 這樣，當開發人員開發ThreeDSecureService時，集成測試將讓開發人員知道他/她已經破壞了集成。 這仍然需要開發人員記住當然實際運行Integration測試。

我認爲它的最終目標是在構建流程中加入一個門，以確保開發人員無法發佈會導致集成測試失敗並與自動部署相結合的更改。這將確保基本的整合錯誤不會使其投入生產。