實用的測試金字塔

功能

應用程式的功能很簡單。它提供一個具有三個端點的 REST 介面

高階結構

在高層級中，系統具有下列結構

圖 3：我們的微服務系統的高層級結構

我們的微服務提供可透過 HTTP 呼叫的 REST 介面。對於某些端點，服務會從資料庫擷取資訊。在其他情況下，服務會透過 HTTP 呼叫外部 天氣 API 以擷取並顯示目前的氣象狀況。

內部架構

在內部，Spring 服務具有 Spring 典型的架構

圖 4：我們的微服務的內部結構

• Controller 類別提供 REST 端點，並處理 HTTP 要求和回應
• Repository 類別與 資料庫 介接，並負責將資料寫入/從持久性儲存裝置讀取資料
• Client 類別與其他 API 對話，在我們的案例中，它會透過 HTTPS 從 darksky.net 天氣 API 擷取 JSON
• Domain 類別擷取我們的 網域模型，包括網域邏輯（在我們的案例中，相當平凡）。

經驗豐富的 Spring 開發人員可能會注意到這裡缺少一個經常使用的層：受到 領域驅動設計 的啟發，許多開發人員會建立由 服務 類別組成的 服務層。我決定不將服務層包含在此應用程式中。原因之一是我們的應用程式夠簡單，服務層會是一個不必要的間接層級。另一個原因是我認為人們過度使用服務層。我經常遇到程式碼庫，其中整個商業邏輯都擷取在服務類別中。網域模型僅成為資料的層級，而非行為（貧血網域模型）。對於每個非平凡的應用程式，這會浪費許多潛力，無法讓您的程式碼保持結構良好且可測試，也無法充分利用物件導向的強大功能。

我們的儲存庫很直接，並提供簡單的 CRUD 功能。為了讓程式碼保持簡單，我使用了 Spring 資料。Spring 資料為我們提供一個簡單且通用的 CRUD 儲存庫實作，我們可以使用它，而不用自己開發。它也會負責在我們的測試中啟動一個記憶體中資料庫，而不是在製作環境中使用真正的 PostgreSQL 資料庫。

檢視程式碼庫，並熟悉內部結構。這將有助於我們執行下一步：測試應用程式！

什麼是單元？

如果你詢問三位不同的人在單元測試中「單元」是什麼意思，你可能會收到四種不同且略有差異的答案。在某種程度上，這是你自己的定義問題，沒有標準答案也沒關係。

如果你使用函式語言，則「單元」很可能是一個單一函式。你的單元測試會呼叫具有不同參數的函式，並確保它傳回預期的值。在物件導向語言中，單元範圍可以從單一方法到整個類別。

群居和獨居

有些人認為，受測對象的所有協作者（例如受測類別呼叫的其他類別）都應該以「模擬」或「存根」取代，以達到完美的隔離，並避免副作用和複雜的測試設定。其他人則認為，只有速度較慢或具有較大副作用的協作者（例如存取資料庫或進行網路呼叫的類別）才應該被存根或模擬。

偶爾，人們會將這兩種測試標記為孤立單元測試（針對存根所有協作者的測試）和社交單元測試（允許與真實協作者對話的測試）（Jay Fields 的 有效使用單元測試 一書創造了這些術語）。如果你有空，可以深入探討並 進一步了解不同思想流派的優缺點。

最後，決定採用孤立或社交單元測試並不重要。撰寫自動化測試才是重點。就我個人而言，我發現自己一直同時使用這兩種方法。如果使用真實協作者變得尷尬，我會大量使用模擬和存根。如果我覺得讓真實協作者參與可以讓我對測試更有信心，我只會存根服務的最外層部分。

模擬和存根

簡單來說，這表示你會用該事物的假版本取代真實事物（例如類別、模組或函式）。假版本看起來和真實事物一樣，也會做出相同的行為（回應相同的方法呼叫），但會回應你在單元測試一開始定義的罐頭回應。

使用測試替身不限於單元測試。更精細的測試替身可以用來以受控的方式模擬系統的整個部分。不過，在單元測試中，你最有可能會遇到許多模擬和存根（取決於你是社交型還是孤立型的開發人員），原因很簡單，因為許多現代語言和函式庫讓設定模擬和存根變得容易且方便。

無論您選擇哪種技術，您的語言標準函式庫或一些熱門的第三方函式庫都有很大的機率會提供您設定模擬的優雅方式。甚至從頭撰寫自己的模擬也只不過是撰寫一個具有與實際函式庫相同簽章的假類別/模組/函式，並在測試中設定假資料。

您的單元測試會執行得非常快。在不錯的機器上，您可以在幾分鐘內執行數千個單元測試。孤立地測試程式碼庫中的小片段，並避免存取資料庫、檔案系統或發出 HTTP 查詢（透過使用這些部分的模擬和存根）以保持測試速度。

一旦您掌握了撰寫單元測試，您將會越來越流暢地撰寫它們。存根外部協作者，設定一些輸入資料，呼叫受測主體，並檢查回傳值是否符合您的預期。深入瞭解測試驅動開發，並讓您的單元測試引導您的開發；如果正確套用，它可以幫助您進入絕佳的流程，並在自動產生全面且完全自動化的測試套件的同時，提出良好且可維護的設計。不過，它並非萬靈丹。繼續吧，給它一個真正的機會，看看它是否適合您。

要測試什麼？

單元測試的好處在於，你可以為所有製作程式碼類別撰寫單元測試，無論其功能為何，或屬於內部結構中的哪一層。你可以像單元測試儲存庫、網域類別或檔案讀取器一樣，單元測試控制器。只要遵守每個製作類別一個測試類別的經驗法則，你就能順利開始。

單元測試類別至少應該測試類別的公開介面。私人方法無法測試，因為你根本無法從不同的測試類別呼叫它們。受保護或封包私人方法可以從測試類別存取（假設測試類別的封包結構與製作類別相同），但測試這些方法可能會太過深入。

撰寫單元測試時，有一條微妙的界線：它們應該確保所有非平凡程式碼路徑都經過測試（包括正常路徑和臨界狀況）。同時，它們不應該與你的實作綁得太緊密。

為什麼呢？

與製作程式碼太過接近的測試會很快變得令人厭煩。只要你重構製作程式碼（快速回顧：重構是指變更程式碼的內部結構，但不會變更外部可見的行為），你的單元測試就會中斷。

這樣一來，你就會失去單元測試的一大好處：作為程式碼變更的安全網。你反而會對這些愚蠢的測試感到厭煩，因為它們會在你每次重構時失敗，造成更多工作，而不是提供幫助；而且，這愚蠢的測試到底是什麼鬼點子？

你該怎麼做？不要在單元測試中反映你的內部程式碼結構。改為測試可觀察的行為。想想

如果我輸入值x和y，結果會是z嗎？

而不是

如果我輸入 x 和 y，方法會先呼叫類別 A，然後呼叫類別 B，再傳回類別 A 的結果加上類別 B 的結果嗎？

私有方法通常應視為實作細節。這就是為什麼你甚至不應該有測試它們的衝動。

我常聽到單元測試（或 TDD ）的對手爭論說，撰寫單元測試會變成毫無意義的工作，因為你必須測試所有方法才能達到高測試涵蓋率。他們常常舉出過於熱心的團隊負責人強迫他們為取得 100% 測試涵蓋率而為取得函數和設定函數以及所有其他瑣碎程式碼撰寫單元測試的範例。

那裡有許多錯誤。

是的，你應該測試公開介面。然而，更重要的是，你不要測試瑣碎的程式碼。別擔心， Kent Beck 認為這沒問題。你不會從測試簡單的取得函數或設定函數或其他瑣碎的實作（例如，沒有任何條件式邏輯）中獲得任何好處。省下時間，這表示你可以參加更多會議，歡呼！

測試結構

所有測試的良好結構（這不限於單元測試）是這個

1. 設定測試資料
2. 呼叫測試中的方法
3. 斷言傳回預期的結果

有一個不錯的記憶技巧可以記住這個結構：「安排、動作、斷言」。另一個你可以使用的技巧是從 BDD 中獲得靈感。它是 「給定」、「何時」、「然後」 三部曲，其中給定反映設定、何時反映方法呼叫，而然後反映斷言部分。

這個模式也可以套用在其他更高級的測試中。在每種情況下，它們都能確保你的測試保持易讀且一致。此外，考量這個結構撰寫的測試往往較短且更具表達力。

實作單元測試

現在我們知道要測試什麼以及如何建構我們的單元測試，我們終於可以看到一個真實的範例。

我們來看看 ExampleController 類別的簡化版本

@RestController
public class ExampleController {

    private final PersonRepository personRepo;

    @Autowired
    public ExampleController(final PersonRepository personRepo) {
        this.personRepo = personRepo;
    }

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepo.findByLastName(lastName);

        return foundPerson
                .map(person -> String.format("Hello %s %s!",
                        person.getFirstName(),
                        person.getLastName()))
                .orElse(String.format("Who is this '%s' you're talking about?",
                        lastName));
    }
}

針對 hello(lastname) 函式的單元測試可以像這樣

public class ExampleControllerTest {

    private ExampleController subject;

    @Mock
    private PersonRepository personRepo;

    @Before
    public void setUp() throws Exception {
        initMocks(this);
        subject = new ExampleController(personRepo);
    }

    @Test
    public void shouldReturnFullNameOfAPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        given(personRepo.findByLastName("Pan"))
            .willReturn(Optional.of(peter));

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Hello Peter Pan!"));
    }

    @Test
    public void shouldTellIfPersonIsUnknown() throws Exception {
        given(personRepo.findByLastName(anyString()))
            .willReturn(Optional.empty());

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Who is this 'Pan' you're talking about?"));
    }
}

我們使用 JUnit 撰寫單元測試，JUnit 是 Java 的事實標準測試架構。我們使用 Mockito 以一個 stub 取代真正的 PersonRepository 類別，以進行我們的測試。這個 stub 讓我們可以定義 stubbed 函式在這個測試中應該回傳的罐頭回應。stubbing 讓我們的測試更簡單、更可預測，而且讓我們可以輕鬆設定測試資料。

遵循 安排、動作、斷言 結構，我們撰寫兩個單元測試 - 一個正向案例和一個找不到搜尋人員的案例。第一個正向測試案例建立一個新的人員物件，並告訴被模擬的儲存庫在以 "Pan" 作為 lastName 參數的值呼叫它時回傳這個物件。然後測試繼續呼叫應該測試的函式。最後，它斷言回應等於預期的回應。

第二個測試運作方式類似，但測試的是測試方法找不到給定參數的人員的情況。

資料庫整合

PersonRepository 是程式碼庫中唯一的儲存庫類別。它依賴於 Spring Data，且沒有實際的實作。它僅延伸 CrudRepository 介面，並提供單一方法標頭。其餘都是 Spring 的魔法。

public interface PersonRepository extends CrudRepository<Person, String> {
    Optional<Person> findByLastName(String lastName);
}

透過 CrudRepository 介面，Spring Boot 提供一個功能齊全的 CRUD 儲存庫，包含 findOne、findAll、save、update 和 delete 方法。我們的自訂方法定義 (findByLastName()) 延伸此基本功能，並提供我們一個透過姓氏擷取 Person 的方法。Spring Data 會分析方法的傳回類型及其方法名稱，並根據命名慣例檢查方法名稱，以找出它應該執行的動作。

儘管 Spring Data 負責執行實作資料庫儲存庫的繁重工作，但我仍撰寫了一個資料庫整合測試。你可能會辯稱這是「測試架構」，而且我應該避免這麼做，因為我們測試的不是我們的程式碼。儘管如此，我相信在此處至少有一個整合測試至關重要。首先，它測試我們的自訂 findByLastName 方法是否實際上按照預期運作。其次，它證明我們的儲存庫正確使用 Spring 的配線，並且可以連線到資料庫。

為了讓你在自己的機器上執行測試更輕鬆（無需安裝 PostgreSQL 資料庫），我們的測試會連線到內建記憶體的 H2 資料庫。

我在 build.gradle 檔案中將 H2 定義為測試依賴項。測試目錄中的 application.properties 沒有定義任何 spring.datasource 屬性。這會指示 Spring Data 使用內建記憶體資料庫。由於它在類別路徑中找到 H2，因此在執行我們的測試時，它會直接使用 H2。

當使用 int 設定檔執行實際應用程式時（例如，透過將 SPRING_PROFILES_ACTIVE=int 設定為環境變數），它會連線到 application-int.properties 中定義的 PostgreSQL 資料庫。

我知道，這需要了解和理解大量的 Spring 細節。為了達成此目標，你必須仔細閱讀 大量文件。產生的程式碼容易閱讀，但如果你不了解 Spring 的細微細節，則很難理解。

此外，使用內建記憶體資料庫是有風險的。畢竟，我們的整合測試執行的是與生產環境中不同的資料庫類型。繼續並自行決定你是否偏好 Spring 的魔法和簡單程式碼，而不是明確但更冗長的實作。

已經說明夠多了，以下是將 Person 儲存到資料庫並依據其姓氏來尋找的簡單整合測試

@RunWith(SpringRunner.class)
@DataJpaTest
public class PersonRepositoryIntegrationTest {
    @Autowired
    private PersonRepository subject;

    @After
    public void tearDown() throws Exception {
        subject.deleteAll();
    }

    @Test
    public void shouldSaveAndFetchPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        subject.save(peter);

        Optional<Person> maybePeter = subject.findByLastName("Pan");

        assertThat(maybePeter, is(Optional.of(peter)));
    }
}

您可以看到我們的整合測試遵循與單元測試相同的安排、動作、斷言結構。告訴您這是一個通用的概念！

與個別服務整合

我們的微服務會與 darksky.net 進行通訊，這是一個天氣 REST API。當然我們希望確保我們的服務會正確地傳送要求並剖析回應。

我們希望在執行自動化測試時避免存取真實的darksky 伺服器。免費方案的配額限制只是原因之一。真正的理由是解耦。我們的測試應該獨立於 darksky.net 的可愛人員正在進行的任何事。即使您的機器無法存取darksky 伺服器或 darksky 伺服器因維護而關閉時也是如此。

我們可以在執行整合測試時執行我們自己的假darksky 伺服器，以避免存取真實的darksky 伺服器。這聽起來可能像是一項龐大的任務。感謝 Wiremock 等工具，這非常容易。請觀看這個

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientIntegrationTest {

    @Autowired
    private WeatherClient subject;

    @Rule
    public WireMockRule wireMockRule = new WireMockRule(8089);

    @Test
    public void shouldCallWeatherService() throws Exception {
        wireMockRule.stubFor(get(urlPathEqualTo("/some-test-api-key/53.5511,9.9937"))
                .willReturn(aResponse()
                        .withBody(FileLoader.read("classpath:weatherApiResponse.json"))
                        .withHeader(CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                        .withStatus(200)));

        Optional<WeatherResponse> weatherResponse = subject.fetchWeather();

        Optional<WeatherResponse> expectedResponse = Optional.of(new WeatherResponse("Rain"));
        assertThat(weatherResponse, is(expectedResponse));
    }
}

要使用 Wiremock，我們在固定連接埠 (8089) 上實例化一個 WireMockRule。使用 DSL，我們可以設定 Wiremock 伺服器，定義它應該監聽的端點，並設定它應該回應的罐頭回應。

接下來，我們呼叫我們想要測試的方法，也就是呼叫第三方服務的方法，並檢查結果是否正確剖析。

了解測試如何知道它應該呼叫假的 Wiremock 伺服器而不是真實的darksky API 非常重要。祕密就在於我們包含在 src/test/resources 中的 application.properties 檔案。這是 Spring 在執行測試時載入的屬性檔案。在這個檔案中，我們使用適合於我們的測試目的的值來覆寫 API 金鑰和 URL 等組態，例如呼叫假的 Wiremock 伺服器而不是真實的伺服器

weather.url = https://127.0.0.1:8089

請注意，這裡定義的連接埠必須與我們在測試中實例化 WireMockRule 時定義的連接埠相同。在我們的測試中，透過在 WeatherClient 類別的建構函式中注入 URL，可以將真實天氣 API 的 URL 替換為假的 URL

@Autowired
public WeatherClient(final RestTemplate restTemplate,
                     @Value("${weather.url}") final String weatherServiceUrl,
                     @Value("${weather.api_key}") final String weatherServiceApiKey) {
    this.restTemplate = restTemplate;
    this.weatherServiceUrl = weatherServiceUrl;
    this.weatherServiceApiKey = weatherServiceApiKey;
}

這樣我們會告訴我們的 WeatherClient 從我們在應用程式屬性中定義的 weather.url 屬性讀取 weatherUrl 參數的值。

使用 Wiremock 等工具為獨立的服務撰寫狹義整合測試非常容易。不幸的是，這種方法有一個缺點：我們如何確保我們設定的假伺服器會像真實的伺服器一樣運作？使用目前的實作，獨立的服務可能會變更其 API，而我們的測試仍然會通過。現在我們僅測試我們的 WeatherClient 是否可以剖析假伺服器傳送的回應。這是一個開始，但非常脆弱。使用端對端測試並針對真實服務的測試實例執行測試，而不是使用假服務，將可以解決這個問題，但會讓我們依賴測試服務的可用性。幸運的是，對於這個兩難問題，有一個更好的解決方案：針對假伺服器和真實伺服器執行合約測試，可以確保我們在整合測試中使用的假伺服器是一個忠實的測試替身。讓我們看看這是如何運作的。

使用者測試（我們的團隊）

我們的微服務使用天氣 API。因此，我們有責任撰寫一個消費者測試，定義我們對微服務和天氣服務之間合約（API）的預期。

首先，我們在 build.gradle 中包含一個用於撰寫 pact 消費者測試的函式庫

testCompile('au.com.dius:pact-jvm-consumer-junit_2.11:3.5.5')

多虧了這個函式庫，我們可以實作消費者測試並使用 pact 的模擬服務

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientConsumerTest {

    @Autowired
    private WeatherClient weatherClient;

    @Rule
    public PactProviderRuleMk2 weatherProvider =
            new PactProviderRuleMk2("weather_provider", "localhost", 8089, this);

    @Pact(consumer="test_consumer")
    public RequestResponsePact createPact(PactDslWithProvider builder) throws IOException {
        return builder
                .given("weather forecast data")
                .uponReceiving("a request for a weather request for Hamburg")
                    .path("/some-test-api-key/53.5511,9.9937")
                    .method("GET")
                .willRespondWith()
                    .status(200)
                    .body(FileLoader.read("classpath:weatherApiResponse.json"),
                            ContentType.APPLICATION_JSON)
                .toPact();
    }

    @Test
    @PactVerification("weather_provider")
    public void shouldFetchWeatherInformation() throws Exception {
        Optional<WeatherResponse> weatherResponse = weatherClient.fetchWeather();
        assertThat(weatherResponse.isPresent(), is(true));
        assertThat(weatherResponse.get().getSummary(), is("Rain"));
    }
}

如果您仔細觀察，您會看到 WeatherClientConsumerTest 與 WeatherClientIntegrationTest 非常類似。這次我們使用 Pact，而不是使用 Wiremock 作為伺服器存根。事實上，消費者測試的工作方式與整合測試完全相同，我們使用存根取代真正的第三方伺服器，定義預期的回應，並檢查我們的客戶端是否可以正確解析回應。從這個意義上來說，WeatherClientConsumerTest 本身就是一個狹隘的整合測試。與基於 Wiremock 的測試相比，這個測試的優點是每次執行時都會產生一個pact 檔案（在 target/pacts/&pact-name>.json 中找到）。此 pact 檔案以一種特殊的 JSON 格式描述我們對合約的預期。然後可以使用此 pact 檔案來驗證我們的存根伺服器是否像真正的伺服器一樣運作。我們可以取得 pact 檔案並將其交給提供介面的團隊。他們會取得此 pact 檔案並使用其中定義的預期撰寫一個提供者測試。這樣，他們可以測試他們的 API 是否符合我們的所有預期。

您看到這就是 CDC 的消費者驅動部分的由來。消費者透過描述他們的預期來驅動介面的實作。提供者必須確保他們滿足所有預期，而且他們已經完成了。沒有鍍金、沒有 YAGNI 和其他東西。

取得契約檔案提供給團隊有多種方式。一種簡單的方式是將它們檢查到版本控制中，並告訴提供者團隊始終擷取契約檔案的最新版本。更進階的方式是使用人工製品儲存庫，例如 Amazon 的 S3 或契約仲介。從簡單開始，並根據需要逐步擴充。

在實際應用中，您不需要同時為客戶端類別執行「整合測試」和「消費者測試」。範例程式碼庫同時包含這兩種測試，以顯示如何使用任一種測試。如果您想要使用契約來撰寫 CDC 測試，建議堅持使用後者。撰寫測試的難度相同。使用契約的好處是，您可以自動取得包含對其他團隊可輕鬆用於實作其提供者測試的合約預期的契約檔案。當然，這只有在您能說服其他團隊也使用契約時才有意義。如果這行不通，使用「整合測試」和 Wiremock 組合是一個不錯的備用方案。

提供者測試（其他團隊）

提供者測試必須由提供天氣 API 的人員實作。我們使用 darksky.net 提供的公開 API。理論上，darksky 團隊會在他們端點實作提供者測試，以檢查他們並未破壞其應用程式和我們的服務之間的合約。

顯然，他們不在乎我們微不足道的範例應用程式，而且不會為我們實作 CDC 測試。這是公開 API 和採用微服務的組織之間的重大差異。公開 API 無法考慮所有單一消費者，否則他們將無法向前邁進。在您自己的組織中，您可以而且應該這麼做。您的應用程式很可能會服務少數，最多可能是幾十個消費者。您將可以順利為這些介面撰寫提供者測試，以維持系統穩定。

提供者團隊取得契約檔案，並針對其提供服務執行該檔案。為此，他們實作一個讀取契約檔案、建立一些測試資料，並針對其服務執行契約檔案中定義的預期的提供者測試。

契約人員已撰寫多個用於實作提供者測試的函式庫。其主要 GitHub 儲存庫 為您提供一份不錯的概觀，說明有哪些消費者和提供者函式庫可用。選擇最符合您的技術堆疊的函式庫。

為求簡潔，我們假設 darksky API 也以 Spring Boot 實作。在此情況下，他們可以使用 Spring 契約提供者，它可以順利連結到 Spring 的 MockMVC 機制。darksky.net 團隊可能會實作的假設提供者測試如下所示

@RunWith(RestPactRunner.class)
@Provider("weather_provider") // same as the "provider_name" in our clientConsumerTest
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class WeatherProviderTest {
    @InjectMocks
    private ForecastController forecastController = new ForecastController();

    @Mock
    private ForecastService forecastService;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        target.setControllers(forecastController);
    }

    @State("weather forecast data") // same as the "given()" in our clientConsumerTest
    public void weatherForecastData() {
        when(forecastService.fetchForecastFor(any(String.class), any(String.class)))
                .thenReturn(weatherForecast("Rain"));
    }
}

您會看到，所有提供者測試所要做的就是載入協定檔案（例如，使用 @PactFolder 註解來載入先前下載的協定檔案），然後定義預先定義狀態的測試資料應如何提供（例如，使用 Mockito 模擬）。沒有自訂測試需要實作。這些都是從協定檔案衍生的。提供者測試具有與使用者測試中宣告的提供者名稱和狀態相符的對應項目非常重要。

提供者測試（我們的團隊）

我們已經了解如何測試我們的服務與天氣提供者之間的合約。透過這個介面，我們的服務扮演使用者，天氣服務扮演提供者。再思考一下，我們會看到我們的服務也扮演其他人的提供者：我們提供一個 REST API，提供幾個端點供其他人使用。

由於我們剛學到合約測試非常流行，我們當然也會為這個合約撰寫合約測試。很幸運的是，我們使用使用者驅動合約，因此所有使用者團隊都會將其協定傳送給我們，我們可以使用這些協定來實作 REST API 的提供者測試。

讓我們先將 Spring 的協定提供者函式庫新增到我們的專案

testCompile('au.com.dius:pact-jvm-provider-spring_2.12:3.5.5')

實作提供者測試遵循前面所述的相同模式。為了簡化起見，我僅從我們的 簡單使用者 中檢查協定檔案到我們的服務儲存庫。這讓我們更容易達成目的，在實際情況中，您可能會使用更精密的機制來分發協定檔案。

@RunWith(RestPactRunner.class)
@Provider("person_provider")// same as in the "provider_name" part in our pact file
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class ExampleProviderTest {

    @Mock
    private PersonRepository personRepository;

    @Mock
    private WeatherClient weatherClient;

    private ExampleController exampleController;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        exampleController = new ExampleController(personRepository, weatherClient);
        target.setControllers(exampleController);
    }

    @State("person data") // same as the "given()" part in our consumer test
    public void personData() {
        Person peterPan = new Person("Peter", "Pan");
        when(personRepository.findByLastName("Pan")).thenReturn(Optional.of
                (peterPan));
    }
}

顯示的 ExampleProviderTest 需要根據我們提供的協定檔案提供狀態，僅此而已。一旦我們執行提供者測試，協定就會擷取協定檔案，並針對我們的服務發出 HTTP 要求，然後根據我們設定的狀態回應。

使用者介面端對端測試

對於端到端測試，Selenium 和 WebDriver 協定是許多開發人員的首選工具。使用 Selenium，你可以選擇你喜歡的瀏覽器，並讓它自動呼叫你的網站，在這裡和那裡按一下，輸入資料，並檢查使用者介面中的內容是否變更。

Selenium 需要一個瀏覽器，它可以啟動並用於執行測試。有許多不同的瀏覽器所謂的「驅動程式」可以使用。 選擇一個（或多個）並將其新增到你的 build.gradle。無論你選擇哪個瀏覽器，你都需要確保團隊中的所有開發人員和你的 CI 伺服器都已在本地安裝正確版本的瀏覽器。保持同步可能很痛苦。對於 Java，有一個不錯的小程式庫稱為 webdrivermanager，它可以自動下載並設定你想要使用的瀏覽器正確版本。將這兩個相依性新增到你的 build.gradle，你就可以開始了

testCompile('org.seleniumhq.selenium:selenium-chrome-driver:2.53.1')
testCompile('io.github.bonigarcia:webdrivermanager:1.7.2')

在你的測試套件中執行一個功能齊全的瀏覽器可能會很麻煩。特別是在使用持續交付時，執行你的管線的伺服器可能無法啟動包括使用者介面在內的瀏覽器（例如，因為沒有可用的 X-Server）。你可以透過啟動一個虛擬 X-Server（例如 xvfb）來解決這個問題。

較新的方法是使用無頭瀏覽器（即沒有使用者介面的瀏覽器）來執行您的 WebDriver 測試。直到最近，PhantomJS 都是用於瀏覽器自動化的領先無頭瀏覽器。自從 Chromium 和 Firefox 宣布在他們的瀏覽器中實作無頭模式以來，PhantomJS 突然變得過時了。畢竟，使用您的使用者實際使用的瀏覽器（例如 Firefox 和 Chrome）來測試您的網站，會比僅因為對您作為開發人員來說方便而使用人工瀏覽器來得好。

無頭 Firefox 和 Chrome 都是全新的，尚未廣泛採用來實作 WebDriver 測試。我們希望讓事情簡單。我們不要忙著使用尖端的無頭模式，而要堅持使用 Selenium 和一般瀏覽器的傳統方式。一個啟動 Chrome、導覽到我們的服務並檢查網站內容的簡單端對端測試如下所示

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ESeleniumTest {

    private WebDriver driver;

    @LocalServerPort
    private int port;

    @BeforeClass
    public static void setUpClass() throws Exception {
        ChromeDriverManager.getInstance().setup();
    }

    @Before
    public void setUp() throws Exception {
        driver = new ChromeDriver();
    }

    @After
    public void tearDown() {
        driver.close();
    }

    @Test
    public void helloPageHasTextHelloWorld() {
        driver.get(String.format("http://127.0.0.1:%s/hello", port));

        assertThat(driver.findElement(By.tagName("body")).getText(), containsString("Hello World!"));
    }
}

請注意，如果您在執行此測試的系統（您的本機電腦、您的 CI 伺服器）上已安裝 Chrome，此測試才會在您的系統上執行。

測試很簡單。它使用 @SpringBootTest 在隨機埠上啟動整個 Spring 應用程式。然後，我們實例化一個新的 Chrome WebDriver，告訴它導覽到我們微服務的 /hello 端點，並檢查它是否在瀏覽器視窗上印出「Hello World！」很酷吧！

REST API 端對端測試

在測試您的應用程式時避免使用圖形使用者介面，會是不錯的方法，可以想出比完整端對端測試不那麼不穩定的測試，同時仍然涵蓋您應用程式堆疊的廣泛部分。當透過應用程式的 Web 介面進行測試特別困難時，這會很方便。也許您甚至沒有 Web UI，而是提供 REST API（因為您在某處有一個與該 API 對話的單一頁面應用程式，或只是因為您鄙視所有漂亮的東西）。無論如何，一個皮下測試僅在圖形使用者介面下方進行測試，而且可以在不影響信心的情況下讓您走得很遠。如果您像我們的範例程式碼一樣提供 REST API，這正是您需要的

@RestController
public class ExampleController {
    private final PersonRepository personRepository;

    // shortened for clarity

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepository.findByLastName(lastName);

        return foundPerson
             .map(person -> String.format("Hello %s %s!",
                     person.getFirstName(),
                     person.getLastName()))
             .orElse(String.format("Who is this '%s' you're talking about?",
                     lastName));
    }
}

讓我向您展示另一個在測試提供 REST API 的服務時派得上用場的函式庫。REST-assured 是一個函式庫，它為您提供一個漂亮的 DSL，用於對 API 發出真正的 HTTP 要求並評估您收到的回應。

首先：將相依項新增到您的 build.gradle。

testCompile('io.rest-assured:rest-assured:3.0.3')

有了這個函式庫，我們可以為我們的 REST API 實作一個端對端測試

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ERestTest {

    @Autowired
    private PersonRepository personRepository;

    @LocalServerPort
    private int port;

    @After
    public void tearDown() throws Exception {
        personRepository.deleteAll();
    }

    @Test
    public void shouldReturnGreeting() throws Exception {
        Person peter = new Person("Peter", "Pan");
        personRepository.save(peter);

        when()
                .get(String.format("https://127.0.0.1:%s/hello/Pan", port))
        .then()
                .statusCode(is(200))
                .body(containsString("Hello Peter Pan!"));
    }
}

同樣地，我們使用 @SpringBootTest 啟動整個 Spring 應用程式。在這個情況下，我們 @Autowire PersonRepository，以便我們可以輕鬆地將測試資料寫入我們的資料庫。當我們現在要求 REST API 對我們的友人「Mr Pan」說「hello」時，我們會收到一個友善的問候。太棒了！如果您甚至沒有 Web 介面，這已經是一個非常足夠的端對端測試了。