對(duì)於像使用React 構(gòu)建的交互式網(wǎng)站，集成測(cè)試是自然而然的選擇。它們驗(yàn)證用戶(hù)與應(yīng)用程序的交互方式，而無(wú)需端到端測(cè)試的額外開(kāi)銷(xiāo)。

本文通過(guò)一個(gè)練習(xí)來(lái)闡述，該練習(xí)從一個(gè)簡(jiǎn)單的網(wǎng)站開(kāi)始，使用單元測(cè)試和集成測(cè)試驗(yàn)證行為，並演示集成測(cè)試如何通過(guò)更少的代碼行實(shí)現(xiàn)更大的價(jià)值。本文內(nèi)容假設(shè)您熟悉React 和JavaScript 中的測(cè)試。熟悉Jest 和React Testing Library 會(huì)有所幫助，但不是必需的。

測(cè)試分為三種類(lèi)型：

• 單元測(cè)試獨(dú)立驗(yàn)證一段代碼。它們易於編寫(xiě)，但可能會(huì)忽略大局。
• 端到端測(cè)試(E2E) 使用自動(dòng)化框架（例如Cypress 或Selenium）像用戶(hù)一樣與您的網(wǎng)站交互：加載頁(yè)面、填寫(xiě)表單、點(diǎn)擊按鈕等。它們通常編寫(xiě)和運(yùn)行速度較慢，但與真實(shí)的用戶(hù)體驗(yàn)非常接近。
• 集成測(cè)試介於兩者之間。它們驗(yàn)證應(yīng)用程序的多個(gè)單元如何協(xié)同工作，但比E2E 測(cè)試更輕量級(jí)。例如，Jest 自帶一些內(nèi)置實(shí)用程序來(lái)促進(jìn)集成測(cè)試；Jest 在後臺(tái)使用jsdom 來(lái)模擬常見(jiàn)的瀏覽器API，其開(kāi)銷(xiāo)小於自動(dòng)化，並且其強(qiáng)大的模擬工具可以模擬外部API 調(diào)用。

另一個(gè)需要注意的地方：在React 應(yīng)用程序中，單元測(cè)試和集成測(cè)試的編寫(xiě)方式相同，使用的工具也相同。

開(kāi)始進(jìn)行React 測(cè)試

我創(chuàng)建了一個(gè)簡(jiǎn)單的React 應(yīng)用程序（可在GitHub 上找到），其中包含一個(gè)登錄表單。我將其連接到reqres.in，這是一個(gè)我發(fā)現(xiàn)用於測(cè)試前端項(xiàng)目的方便的API。

您可以成功登錄：

…或者遇到來(lái)自API 的錯(cuò)誤消息：

代碼結(jié)構(gòu)如下：

 <code>LoginModule/ ├── components/ │ ├── Login.js // 渲染LoginForm、錯(cuò)誤消息和登錄確認(rèn)│ └── LoginForm.js // 渲染登錄表單字段和按鈕├── hooks/ │ └── useLogin.js // 連接到API 并管理狀態(tài)└── index.js // 將所有內(nèi)容整合在一起</code>

選項(xiàng)1：?jiǎn)卧獪y(cè)試

如果您像我一樣喜歡編寫(xiě)測(cè)試——也許戴著耳機(jī)，在Spotify 上播放著不錯(cuò)的音樂(lè)——那麼您可能會(huì)忍不住為每個(gè)文件編寫(xiě)單元測(cè)試。

即使您不是測(cè)試愛(ài)好者，您也可能正在參與一個(gè)“試圖做好測(cè)試”的項(xiàng)目，但沒(méi)有明確的策略，測(cè)試方法是“我想每個(gè)文件都應(yīng)該有自己的測(cè)試？”

這看起來(lái)像這樣（為了清晰起見(jiàn)，我在測(cè)試文件名中添加了unit）：

 <code>LoginModule/ ├── components/ │  ├── Login.js │  ├── Login.unit.test.js │  ├── LoginForm.js │  └── LoginForm.unit.test.js ├── hooks/ │  ├── useLogin.js │  └── useLogin.unit.test.js ├── index.js └── index.unit.test.js</code>

我在GitHub 上完成了添加所有這些單元測(cè)試的練習(xí)，並創(chuàng)建了一個(gè)test:coverage:unit 腳本以生成覆蓋率報(bào)告（Jest 的內(nèi)置功能）。我們可以通過(guò)四個(gè)單元測(cè)試文件實(shí)現(xiàn)100% 的覆蓋率：

100% 的覆蓋率通常是過(guò)度的，但對(duì)於如此簡(jiǎn)單的代碼庫(kù)來(lái)說(shuō)是可以實(shí)現(xiàn)的。

讓我們深入研究為onLogin React hook 創(chuàng)建的單元測(cè)試之一。如果您不熟悉React hook 或如何測(cè)試它們，請(qǐng)不要擔(dān)心。

 test('successful login flow', async () => {
 // 模擬成功的API 響應(yīng) jest
  .spyOn(window, 'fetch')
  .mockResolvedValue({ json: () => ({ token: '123' }) });

 const { result, waitForNextUpdate } = renderHook(() => useLogin());

 act(() => {
  result.current.onSubmit({
   email: '[email protected]',
   password: 'password',
  });
 });

 // 將狀態(tài)設(shè)置為pending
 expect(result.current.state).toEqual({
  status: 'pending',
  user: null,
  error: null,
 });

 await waitForNextUpdate();

 // 將狀態(tài)設(shè)置為resolved，存儲(chǔ)電子郵件地址 expect(result.current.state).toEqual({
  status: 'resolved',
  user: {
   email: '[email protected]',
  },
  error: null,
 });
});

這個(gè)測(cè)試寫(xiě)起來(lái)很有趣（因?yàn)镽eact Hooks Testing Library 使測(cè)試hook 變得輕而易舉），但它有一些問(wèn)題。

首先，測(cè)試驗(yàn)證內(nèi)部狀態(tài)從'pending' 更改為'resolved'；此實(shí)現(xiàn)細(xì)節(jié)不會(huì)向用戶(hù)公開(kāi)，因此，可能不是要測(cè)試的好東西。如果我們重構(gòu)應(yīng)用程序，我們將不得不更新此測(cè)試，即使從用戶(hù)的角度來(lái)看沒(méi)有任何變化。

此外，作為單元測(cè)試，這只是其中一部分。如果我們想驗(yàn)證登錄流程的其他功能，例如提交按鈕文本更改為“加載中”，我們將不得不在不同的測(cè)試文件中進(jìn)行操作。

選項(xiàng)2：集成測(cè)試

讓我們考慮添加一個(gè)集成測(cè)試來(lái)驗(yàn)證此流程的替代方法：

 <code>LoginModule/ ├── components/ │  ├── Login.js │  └── LoginForm.js ├── hooks/ │  └── useLogin.js ├── index.js └── index.integration.test.js</code>

我實(shí)現(xiàn)了這個(gè)測(cè)試和一個(gè)test:coverage:integration 腳本以生成覆蓋率報(bào)告。就像單元測(cè)試一樣，我們可以達(dá)到100% 的覆蓋率，但這次都在一個(gè)文件中，並且需要的代碼行更少。

以下是涵蓋成功登錄流程的集成測(cè)試：

 test('successful login', async () => {
  jest
    .spyOn(window, 'fetch')
    .mockResolvedValue({ json: () => ({ token: '123' }) });

  render(<loginmodule></loginmodule> );

  const emailField = screen.getByRole('textbox', { name: 'Email' });
  const passwordField = screen.getByLabelText('Password');
  const button = screen.getByRole('button');

  // 填寫(xiě)並提交表單fireEvent.change(emailField, { target: { value: '[email protected]' } });
  fireEvent.change(passwordField, { target: { value: 'password' } });
  fireEvent.click(button);

  // 它設(shè)置加載狀態(tài)expect(button).toBeDisabled();
  expect(button).toHaveTextContent('Loading...');

  await waitFor(() => {
    // 它隱藏表單元素expect(button).not.toBeInTheDocument();
    expect(emailField).not.toBeInTheDocument();
    expect(passwordField).not.toBeInTheDocument();

    // 它顯示成功文本和電子郵件地址const loggedInText = screen.getByText('Logged in as');
    expect(loggedInText).toBeInTheDocument();
    const emailAddressText = screen.getByText('[email protected]');
    expect(emailAddressText).toBeInTheDocument();
  });
});

我真的很喜歡這個(gè)測(cè)試，因?yàn)樗鼜挠脩?hù)的角度驗(yàn)證了整個(gè)登錄流程：表單、加載狀態(tài)和成功確認(rèn)消息。集成測(cè)試非常適合React 應(yīng)用程序，正是因?yàn)檫@種用例；用戶(hù)體驗(yàn)是我們想要測(cè)試的內(nèi)容，而這幾乎總是涉及多個(gè)不同的代碼片段協(xié)同工作。

此測(cè)試不了解使預(yù)期行為起作用的組件或hook，這很好。只要用戶(hù)體驗(yàn)保持不變，我們就可以重寫(xiě)和重構(gòu)這些實(shí)現(xiàn)細(xì)節(jié)而不會(huì)破壞測(cè)試。

我不會(huì)深入研究登錄流程的初始狀態(tài)和錯(cuò)誤處理的其他集成測(cè)試，但我鼓勵(lì)您在GitHub 上查看它們。

那麼，什麼需要單元測(cè)試？

與其考慮單元測(cè)試與集成測(cè)試，不如讓我們退一步，考慮一下我們?nèi)绾螞Q定首先需要測(cè)試什麼。需要測(cè)試LoginModule，因?yàn)樗且粋€(gè)我們希望使用者（應(yīng)用程序中的其他文件）能夠放心地使用的實(shí)體。

另一方面，不需要測(cè)試onLogin hook，因?yàn)樗皇荓oginModule 的實(shí)現(xiàn)細(xì)節(jié)。但是，如果我們的需求發(fā)生變化，並且onLogin 在其他地方有用例，那麼我們將需要添加我們自己的（單元）測(cè)試來(lái)驗(yàn)證其作為可重用實(shí)用程序的功能。 （我們也需要移動(dòng)該文件，因?yàn)樗辉偬囟禠oginModule 了。）

單元測(cè)試仍然有很多用例，例如需要驗(yàn)證可重用選擇器、hook 和普通函數(shù)。在開(kāi)發(fā)代碼時(shí)，您可能還會(huì)發(fā)現(xiàn)使用單元測(cè)試進(jìn)行測(cè)試驅(qū)動(dòng)開(kāi)發(fā)很有幫助，即使您稍後將該邏輯向上移動(dòng)到集成測(cè)試。

此外，單元測(cè)試在針對(duì)多個(gè)輸入和用例進(jìn)行詳盡測(cè)試方面做得很好。例如，如果我的表單需要針對(duì)各種場(chǎng)景（例如無(wú)效電子郵件、缺少密碼、密碼過(guò)短）顯示內(nèi)聯(lián)驗(yàn)證，我將在集成測(cè)試中涵蓋一個(gè)代表性案例，然後在單元測(cè)試中深入研究具體案例。

其他好處

既然我們?cè)谶@裡，我想談?wù)勔恍椭业募蓽y(cè)試保持清晰和有序的語(yǔ)法技巧。

清晰的waitFor 塊

我們的測(cè)試需要考慮LoginModule 的加載狀態(tài)和成功狀態(tài)之間的延遲：

 const button = screen.getByRole('button');
fireEvent.click(button);

expect(button).not.toBeInTheDocument(); // 太快了，按鈕還在！

我們可以使用DOM Testing Library 的waitFor 輔助函數(shù)來(lái)做到這一點(diǎn)：

 const button = screen.getByRole('button');
fireEvent.click(button);

await waitFor(() => {
 expect(button).not.toBeInTheDocument(); // 啊，好多了});

但是，如果我們還想測(cè)試其他一些項(xiàng)目呢？網(wǎng)上沒(méi)有很多關(guān)於如何處理此問(wèn)題的好的示例，並且在過(guò)去的項(xiàng)目中，我已經(jīng)將其他項(xiàng)目放在waitFor 之外：

 // 等待按鈕await waitFor(() => {
 expect(button).not.toBeInTheDocument();
});

// 然後測(cè)試確認(rèn)消息const confirmationText = getByText('Logged in as [email protected]');
expect(confirmationText).toBeInTheDocument();

這有效，但我不喜歡它，因?yàn)樗拱粹o條件看起來(lái)很特殊，即使我們可以輕鬆地切換這些語(yǔ)句的順序：

 // 等待確認(rèn)消息await waitFor(() => {
 const confirmationText = getByText('Logged in as [email protected]');
 expect(confirmationText).toBeInTheDocument();
});

// 然後測(cè)試按鈕expect(button).not.toBeInTheDocument();

在我看來(lái)，將與相同更新相關(guān)的所有內(nèi)容一起分組到waitFor 回調(diào)中要好得多：

 await waitFor(() => {
 expect(button).not.toBeInTheDocument();

 const confirmationText = screen.getByText('Logged in as [email protected]');
 expect(confirmationText).toBeInTheDocument();
});

對(duì)於像這樣的簡(jiǎn)單斷言，我真的很喜歡這種技術(shù)，但在某些情況下，它可能會(huì)減慢測(cè)試速度，等待在waitFor 之外立即發(fā)生的失敗。有關(guān)此示例，請(qǐng)參閱React Testing Library 常用錯(cuò)誤中的“在單個(gè)waitFor 回調(diào)中有多個(gè)斷言”。

對(duì)於包含幾個(gè)步驟的測(cè)試，我們可以連續(xù)使用多個(gè)waitFor 塊：

 const button = screen.getByRole('button');
const emailField = screen.getByRole('textbox', { name: 'Email' });

// 填寫(xiě)表單fireEvent.change(emailField, { target: { value: '[email protected]' } });

await waitFor(() => {
 // 檢查按鈕是否已啟用 expect(button).not.toBeDisabled();
  expect(button).toHaveTextContent('Submit');
});

// 提交表單fireEvent.click(button);

await waitFor(() => {
 // 檢查按鈕是否不再存在 expect(button).not.toBeInTheDocument();
});

如果您只等待一個(gè)項(xiàng)目出現(xiàn)，則可以使用findBy 查詢(xún)代替。它在後臺(tái)使用waitFor。

行內(nèi)it 註釋

另一個(gè)測(cè)試最佳實(shí)踐是編寫(xiě)更少、更長(zhǎng)的測(cè)試；這使您可以將測(cè)試用例與重要的用戶(hù)流程關(guān)聯(lián)起來(lái)，同時(shí)使測(cè)試保持隔離，以避免意外行為。我贊成這種方法，但它在保持代碼組織和記錄所需行為方面可能會(huì)帶來(lái)挑戰(zhàn)。我們需要未來(lái)的開(kāi)發(fā)人員能夠返回測(cè)試並了解它在做什麼，為什麼它會(huì)失敗等等。

例如，假設(shè)這些期望之一開(kāi)始失?。?/p>

 it('handles a successful login flow', async () => {
 // 為清晰起見(jiàn)隱藏測(cè)試的開(kāi)頭?
  expect(button).toBeDisabled();
  expect(button).toHaveTextContent('Loading...');
?
 await waitFor(() => {
  expect(button).not.toBeInTheDocument();
  expect(emailField).not.toBeInTheDocument();
  expect(passwordField).not.toBeInTheDocument();
?
  const confirmationText = screen.getByText('Logged in as [email protected]');
  expect(confirmationText).toBeInTheDocument();
 });
});

查看此內(nèi)容的開(kāi)發(fā)人員無(wú)法輕鬆確定正在測(cè)試的內(nèi)容，並且可能難以確定失敗是錯(cuò)誤（這意味著我們應(yīng)該修復(fù)代碼）還是行為更改（這意味著我們應(yīng)該修復(fù)測(cè)試）。

我最喜歡的解決方案是使用每個(gè)測(cè)試的鮮為人知的測(cè)試語(yǔ)法，並添加描述正在測(cè)試的每個(gè)關(guān)鍵行為的行內(nèi)it 樣式註釋?zhuān)?/p>

 test('successful login', async () => {
 // 為清晰起見(jiàn)隱藏測(cè)試的開(kāi)頭?
 // 它設(shè)置加載狀態(tài) expect(button).toBeDisabled();
  expect(button).toHaveTextContent('Loading...');
?
 await waitFor(() => {
  // 它隱藏表單元素  expect(button).not.toBeInTheDocument();
  expect(emailField).not.toBeInTheDocument();
  expect(passwordField).not.toBeInTheDocument();
?
  // 它顯示成功文本和電子郵件地址  const confirmationText = screen.getByText('Logged in as [email protected]');
  expect(confirmationText).toBeInTheDocument();
 });
});

這些註釋不會(huì)神奇地與Jest 集成，因此如果您遇到失敗，失敗的測(cè)試名稱(chēng)將對(duì)應(yīng)於您傳遞給測(cè)試標(biāo)籤的參數(shù)，在本例中為“successful login”。但是，Jest 的錯(cuò)誤消息包含周?chē)拇a，因此這些it 註釋仍然有助於識(shí)別失敗的行為。當(dāng)我從一個(gè)期望中刪除not 時(shí)，我收到了以下錯(cuò)誤消息：

為了獲得更明確的錯(cuò)誤，有一個(gè)名為jest-expect-message 的包允許您為每個(gè)期望定義錯(cuò)誤消息：

 expect(button, 'button is still in document').not.toBeInTheDocument();

一些開(kāi)發(fā)人員更喜歡這種方法，但我發(fā)現(xiàn)它在大多數(shù)情況下有點(diǎn)太granular 了，因?yàn)閱蝹€(gè)it 通常涉及多個(gè)期望。

團(tuán)隊(duì)的後續(xù)步驟

有時(shí)我希望我們可以為人類(lèi)製定linter 規(guī)則。如果是這樣，我們可以為我們的團(tuán)隊(duì)設(shè)置一個(gè)prefer-integration-tests 規(guī)則，然後就結(jié)束了。

但是，唉，我們需要找到一個(gè)更類(lèi)似的解決方案來(lái)鼓勵(lì)開(kāi)發(fā)人員在某些情況下選擇集成測(cè)試，例如我們前面介紹的LoginModule 示例。像大多數(shù)事情一樣，這歸結(jié)於團(tuán)隊(duì)討論您的測(cè)試策略，就對(duì)項(xiàng)目有意義的內(nèi)容達(dá)成一致，並且——希望——在ADR 中記錄它。

在製定測(cè)試計(jì)劃時(shí)，我們應(yīng)該避免一種會(huì)迫使開(kāi)發(fā)人員為每個(gè)文件編寫(xiě)測(cè)試的文化。開(kāi)發(fā)人員需要能夠放心地做出明智的測(cè)試決策，而不必?fù)?dān)心他們“測(cè)試不足”。 Jest 的覆蓋率報(bào)告可以通過(guò)提供一個(gè)健全性檢查來(lái)幫助解決這個(gè)問(wèn)題，即使測(cè)試在集成級(jí)別上進(jìn)行了合併。

我仍然不認(rèn)為自己是集成測(cè)試專(zhuān)家，但是進(jìn)行這項(xiàng)練習(xí)幫助我分解了一個(gè)集成測(cè)試比單元測(cè)試提供更大價(jià)值的用例。我希望與您的團(tuán)隊(duì)分享這一點(diǎn)，或者在您的代碼庫(kù)上進(jìn)行類(lèi)似的練習(xí)，將有助於指導(dǎo)您將集成測(cè)試納入您的工作流程。

以上是反應(yīng)集成測(cè)試：覆蓋範(fàn)圍更大，測(cè)試較少的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！