在這篇文章中，我將逐步介紹使用測試庫測試依賴上下文的 React 元件的思考過程。我的目標(biāo)是探索一種不同的方法來測試這些元件，檢查使用模擬與不模擬上下文的測試的優(yōu)缺點(diǎn)。我們將研究每種方法如何影響測試的可靠性，並且我將分享關(guān)於何時(shí)以及為什麼一種方法在實(shí)際應(yīng)用中可能比另一種方法更有益的見解。

你應(yīng)該知道什麼

• reactjs 是用來做什麼的（可能你已經(jīng)寫過一些應(yīng)用了）
• 什麼是 vitest

什麼是反應(yīng)上下文

ReactJS 上下文的出現(xiàn)是為了解決 ReactJS 元件結(jié)構(gòu)中的一個(gè)常見問題：道具鑽探。當(dāng)我們有一系列組件需要存取同一組資料時(shí)，就會(huì)發(fā)生道具鑽探。上下文機(jī)制允許元件共享同一組數(shù)據(jù)，只要上下文本身是第一個(gè)後代。

在reactjs文檔中，使用了保存主題的上下文，因?yàn)槠渌M件可能需要此信息，文檔使用上下文來處理該信息，而不是通過道具傳遞值。另一個(gè)範(fàn)例是使用上下文來保存應(yīng)用程式的佈局，在 json-tool 範(fàn)例中，App.tsx 使用可用於所有應(yīng)用程式的 DefaultLayout 上下文來包裝應(yīng)用程式。

本範(fàn)例的應(yīng)用程式

下面的範(fàn)例將使用主題應(yīng)用程式。它是一個(gè)允許用戶在淺色/深色主題之間切換的應(yīng)用程式。該應(yīng)用程式也在reactjs官方文件中使用。該應(yīng)用程式由一個(gè)簡單的開關(guān)組成，可在淺色主題模式和深色主題模式之間切換。該應(yīng)用程式非常簡單，我們可以將所有內(nèi)容繪製在一個(gè)檔案中：

import { createContext, useContext, useState } from 'react'
const ThemeContext = createContext('light')

function Page() {
  const theme = useContext(ThemeContext)
  return (
    <div>
      <p>current theme: {theme}</p>
    </div>
  )
}

function App() {
  const [theme, setTheme] = useState('light')
  return (
    <ThemeContext.Provider value={theme}>
      <button
        className={theme}
        onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}
      >
        Toggle
      </button>
      <Page />
    </ThemeContext.Provider>
  )
}

export default App

在這個(gè)應(yīng)用程式中，我們有兩個(gè)主要元件：App 和 Page。 App 元件作為主要元件，包含目前主題的狀態(tài)，可以是「亮」或「暗」。它還包括一個(gè)可在淺色和深色模式之間切換主題的按鈕。 Page 元件是 App 的子元件，它使用主題上下文來顯示目前主題。 App 元件中的按鈕是一個(gè)簡單的切換按鈕，點(diǎn)擊時(shí)會(huì)切換主題並相應(yīng)地更新上下文值。

在下一節(jié)中，我們將討論對(duì)組件進(jìn)行切片以進(jìn)行測試。

點(diǎn)火測試

通常在任何應(yīng)用程式中，我們都必須專注於我們想要做什麼樣的測試，以及我們想要處理哪個(gè)部分。例如，我們可以針對(duì)單一元件，而不是整個(gè)應(yīng)用程式。在我們的範(fàn)例中，我們將從頁面元件開始。這將需要我們使用測試替身來測試它。

測試替身來自應(yīng)用程式結(jié)構(gòu)本身，因?yàn)樗Q於上下文，要更改它，上下文中的值也需要更改。

測試雙打

為了開始使用 ReactJS 中的上下文進(jìn)行測試方法，我們將開始編寫第一個(gè)測試：

import { createContext, useContext, useState } from 'react'
const ThemeContext = createContext('light')

function Page() {
  const theme = useContext(ThemeContext)
  return (
    <div>
      <p>current theme: {theme}</p>
    </div>
  )
}

function App() {
  const [theme, setTheme] = useState('light')
  return (
    <ThemeContext.Provider value={theme}>
      <button
        className={theme}
        onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}
      >
        Toggle
      </button>
      <Page />
    </ThemeContext.Provider>
  )
}

export default App

鑑於淺色主題設(shè)定為 ThemeContext 中的預(yù)設(shè)主題，此測試將按預(yù)期通過。我們甚至可以測試第一個(gè)範(fàn)例，但是，當(dāng)我們對(duì)黑暗主題感興趣時(shí)，第二個(gè)測試中的事情會(huì)變得有趣。為了進(jìn)入黑暗主題，我們需要開始使用測試替身，因?yàn)槲覀円蕾?ReactJS 上下文來做到這一點(diǎn)。第二個(gè)測試將 vi.mock 和 vi.mocked 混合在一起。請(qǐng)注意，要編寫的第二個(gè)測試也需要更改第一個(gè)測試。

import { render, screen } from '@testing-library/react'
import { Page } from './Page'

describe('<Page />', () => {
  it('should render light as default theme', () => {
    render(<Page />)
    expect(screen.getByText('current theme: light')).toBeInTheDocument()
  })
})

兩個(gè)測試案例現(xiàn)在都使用假的來測試驅(qū)動(dòng)應(yīng)用程式。如果我們改變上下文的回傳數(shù)據(jù)，測試也會(huì)改變。這裡的注意點(diǎn)是：

• 我們正在嘲笑reactjs上下文，這違背了「不要嘲笑你不擁有的東西」的原則
• 測試變得更加冗長，因?yàn)槲覀冃枰褂媚M來做到這一點(diǎn)
• 我們寫的兩個(gè)測試沒有反映使用者與應(yīng)用程式的互動(dòng)。我們知道，當(dāng)按下切換按鈕時(shí)，主題將會(huì)改變。

本節(jié)中使用的完整程式碼可在 GitHub 上取得

沒有測試替身

下一個(gè)方法是使用嵌入到我們的應(yīng)用程式中的上下文，而不隔離它或使用任何測試替身。如果我們採用 TDD 的這種方法，我們可以從一個(gè)非常簡單的測試開始，模擬使用者的行為方式：

import { render, screen } from '@testing-library/react'
import { Page } from './Page'
import { useContext } from 'react'

vi.mock('react', () => {
  return {
    ...vi.importActual('react'),
    useContext: vi.fn(),
    createContext: vi.fn()
  }
})

describe('<Page />', () => {
  it('should render light as default theme', () => {
    vi.mocked(useContext).mockReturnValue('light')
    render(<Page />)
    expect(screen.getByText('current theme: light')).toBeInTheDocument()
  })

  it('should render dark theme', () => {
    vi.mocked(useContext).mockReturnValue('dark')
    render(<Page />)
    expect(screen.getByText('current theme: dark')).toBeInTheDocument()
  })
})

然後進(jìn)行第二個(gè)測試，我們希望預(yù)設(shè)燈光主題：

import { render, screen } from '@testing-library/react'
import App from './App'
import userEvent from '@testing-library/user-event'

describe('<App />', () => {
  it('should render toggle button', () => {
    render(<App />)
    expect(screen.getByText('Toggle')).toBeInTheDocument()
  })
})

最後但並非最不重要的主題切換：

import { render, screen } from '@testing-library/react'
import App from './App'
import userEvent from '@testing-library/user-event'

describe('<App />', () => {
  it('should render toggle button', () => {
    render(<App />)
    expect(screen.getByText('Toggle')).toBeInTheDocument()
  })

  it('should render light as default theme', () => {
    render(<App />)
    expect(screen.getByText('current theme: light')).toBeInTheDocument()
  })
})

本攻略注意：

• 不需要測試替身，它可以用更少的程式碼進(jìn)行測試
• 測試的行為與使用者在真實(shí)應(yīng)用程式中的行為相符

本節(jié)中使用的完整程式碼可在 GitHub 上取得

每種方法的優(yōu)缺點(diǎn)

在本節(jié)中，我們將討論每種方法針對(duì)不同屬性的優(yōu)缺點(diǎn)。

重構(gòu) props

在上下文中使用測試替身會(huì)使測試對(duì)於這種更改變得脆弱。使用 props 重構(gòu) useContext 的使用會(huì)自動(dòng)使測試失敗，即使行為沒有失敗。使用不使用測試雙精度的選項(xiàng)支援在這個(gè)意義上的重構(gòu)。

建立自訂上下文

使用自訂上下文而不是直接依賴reactjs 的上下文提供者也會(huì)發(fā)生相同的情況。使用不帶測試替身的選項(xiàng)可以進(jìn)行重構(gòu)。

結(jié)論

在本指南中，我們探索瞭如何測試依賴於上下文的組件，而不需要測試替身，使測試更加簡單，更接近真實(shí)的用戶交互，並對(duì)比每種方法的優(yōu)缺點(diǎn)。只要有可能，就應(yīng)遵循反映使用者互動(dòng)的簡單方法。然而，當(dāng)需要測試替身時(shí)，應(yīng)該以測試程式碼的可維護(hù)性為目標(biāo)來使用它們。透過簡單的測試可以放心地重構(gòu)生產(chǎn)程式碼。

資源

• 建立自訂上下文
• 重構(gòu)目錄
• 用來尋找如何使用 vitest 模擬模組的特定部分
• 用於尋找如何解決類型問題
• 測試庫 userEvent

下一步

• 嘗試測試涉及多個(gè)上下文或巢狀提供者的更複雜的場景。
• 雖然我們?cè)诒局改现斜苊饬四M，但在某些情況下模擬是必要的。探索這些場景的高級(jí)模擬技術(shù)。

遵循這些步驟，您可以繼續(xù)提高測試技能並確保您的 React 應(yīng)用程式可以重構(gòu)。

以上是測試 ReactJS 上下文 - 測試替身指南的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！