測試 ReactJS 上下文 - 測試替身指南

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

你應該知道什麼

• reactjs 是用來做什麼的（可能你已經寫過一些應用了）
• 什麼是 vitest

什麼是反應上下文

ReactJS 上下文的出現是為了解決 ReactJS 元件結構中的一個常見問題：道具鑽探。當我們有一系列組件需要存取同一組資料時，就會發生道具鑽探。上下文機制允許元件共享同一組數據，只要上下文本身是第一個後代。

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

本範例的應用程式

下面的範例將使用主題應用程式。它是一個允許用戶在淺色/深色主題之間切換的應用程式。該應用程式也在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></page>
    </themecontext.provider>
  )
}

export default App

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

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

點火測試

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

測試替身來自應用程式結構本身，因為它取決於上下文，要更改它，上下文中的值也需要更改。

測試雙打

為了開始使用 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></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></page>', () => {
  it('should render light as default theme', () => {
    render(<page></page>)
    expect(screen.getByText('current theme: light')).toBeInTheDocument()
  })
})

兩個測試案例現在都使用假的來測試驅動應用程式。如果我們改變上下文的回傳數據，測試也會改變。這裡的注意點是：

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

本節中使用的完整程式碼可在 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></page>', () => {
  it('should render light as default theme', () => {
    vi.mocked(useContext).mockReturnValue('light')
    render(<page></page>)
    expect(screen.getByText('current theme: light')).toBeInTheDocument()
  })

  it('should render dark theme', () => {
    vi.mocked(useContext).mockReturnValue('dark')
    render(<page></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></app>', () => {
  it('should render toggle button', () => {
    render(<app></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></app>', () => {
  it('should render toggle button', () => {
    render(<app></app>)
    expect(screen.getByText('Toggle')).toBeInTheDocument()
  })

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

本攻略注意：

• 不需要測試替身，它可以用更少的程式碼進行測試
• 測試的行為與使用者在真實應用程式中的行為相符

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

每種方法的優缺點

在本節中，我們將討論每種方法針對不同屬性的優缺點。

重構 props

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

建立自訂上下文

使用自訂上下文而不是直接依賴reactjs 的上下文提供者也會發生相同的情況。使用不帶測試替身的選項可以進行重構。

結論

在本指南中，我們探索瞭如何測試依賴於上下文的組件，而不需要測試替身，使測試更加簡單，更接近真實的用戶交互，並對比每種方法的優缺點。只要有可能，就應遵循反映使用者互動的簡單方法。然而，當需要測試替身時，應該以測試程式碼的可維護性為目標來使用它們。透過簡單的測試可以放心地重構生產程式碼。

資源

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

下一步

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

遵循這些步驟，您可以繼續提高測試技能並確保您的 React 應用程式可以重構。

以上是測試 ReactJS 上下文 - 測試替身指南的詳細內容。更多資訊請關注PHP中文網其他相關文章！