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

你應該知道什么

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

什么是反應上下文

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

在reactjs文檔中，使用了保存主題的上下文，因為其他組件可能需要此信息，文檔使用上下文來處理該信息，而不是通過道具傳遞值。另一個示例是使用上下文來保存應用程序的布局，在 json-tool 示例中，App.tsx 使用可用于所有應用程序的 DefaultLayout 上下文來包裝應用程序。

本示例的應用程序

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

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

在這個應用程序中，我們有兩個主要組件：App 和 Page。 App 組件作為主要組件，包含當前主題的狀態(tài)，可以是“亮”或“暗”。它還包括一個可在淺色和深色模式之間切換主題的按鈕。 Page 組件是 App 的子組件，它使用主題上下文來顯示當前主題。 App 組件中的按鈕是一個簡單的切換按鈕，單擊時會切換主題并相應地更新上下文值。

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

點火測試

通常在任何應用程序中，我們都必須專注于我們想要做什么樣的測試，以及我們想要處理哪個部分。例如，我們可以針對單個組件，而不是整個應用程序。在我們的示例中，我們將從頁面組件開始。這將需要我們使用測試替身來測試它。

測試替身來自應用程序結(jié)構(gòu)本身，因為它取決于上下文，要更改它，上下文中的值也需要更改。

測試雙打

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

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

鑒于淺色主題設置為 ThemeContext 中的默認主題，此測試將按預期通過。我們甚至可以測試第一個示例，但是，當我們對黑暗主題感興趣時，第二個測試中的事情會變得有趣。為了進入黑暗主題，我們需要開始使用測試替身，因為我們依賴于 ReactJS 上下文來做到這一點。第二個測試將 vi.mock 和 vi.mocked 混合在一起。請注意，要編寫的第二個測試也需要更改第一個測試。

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()
  })
})

兩個測試用例現(xiàn)在都使用假的來測試驅(qū)動應用程序。如果我們改變上下文的返回數(shù)據(jù)，測試也會改變。這里的注意點是：

• 我們正在嘲笑reactjs上下文，這違背了“不要嘲笑你不擁有的東西”的原則
• 測試變得更加冗長，因為我們需要使用模擬來做到這一點
• 我們編寫的兩個測試沒有反映用戶與應用程序的交互。我們知道，當按下切換按鈕時，主題將會改變。

本節(jié)中使用的完整代碼可在 GitHub 上獲取

沒有測試替身

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

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()
  })
})

然后進行第二個測試，我們希望默認設置燈光主題：

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()
  })
})

本攻略注意點：

• 不需要測試替身，它可以用更少的代碼進行測試
• 測試的行為與用戶在真實應用程序中的行為相匹配

本節(jié)中使用的完整代碼可在 GitHub 上獲取

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

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

重構(gòu) props

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

創(chuàng)建自定義上下文

使用自定義上下文而不是直接依賴reactjs 的上下文提供程序也會發(fā)生同樣的情況。使用不帶測試替身的選項可以進行重構(gòu)。

結(jié)論

在本指南中，我們探索了如何測試依賴于上下文的組件，而不需要測試替身，使測試更加簡單，更接近真實的用戶交互，并對比每種方法的優(yōu)缺點。只要有可能，就應遵循反映用戶交互的簡單方法。然而，當需要測試替身時，應該以測試代碼的可維護性為目標來使用它們。通過簡單的測試可以放心地重構(gòu)生產(chǎn)代碼。

資源

• 創(chuàng)建自定義上下文
• 重構(gòu)目錄
• 用于查找如何使用 vitest 模擬模塊的特定部分
• 用于查找如何解決類型問題
• 測試庫 userEvent

下一步

• 嘗試測試涉及多個上下文或嵌套提供程序的更復雜的場景。
• 雖然我們在本指南中避免了模擬，但在某些情況下模擬是必要的。探索這些場景的高級模擬技術。

通過遵循這些步驟，您可以繼續(xù)提高測試技能并確保您的 React 應用程序可以重構(gòu)。

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