この投稿では、テスト ライブラリを使用して、コンテキストに依存する React コンポーネントをテストするための思考プロセスを説明します。私の目的は、これらのコンポーネントをテストするための別のアプローチを検討し、モックを使用する場(chǎng)合とコンテキストをモックせずにテストする場(chǎng)合の長(zhǎng)所と短所を検討することです。それぞれのアプローチがテストの信頼性にどのような影響を與えるかを見ていき、実際のアプリケーションにおいて、ある方法が他の方法よりも有益である場(chǎng)合とその理由についての洞察を共有します。

知っておくべきこと

• reactjs の使用目的 (おそらく、すでにいくつかのアプリを作成したことがあるでしょう)
• ヴィテストとは

反応コンテキストとは何ですか

ReactJS コンテキストは、ReactJS コンポーネントの構(gòu)造における一般的な問題、つまりプロップドリルの解決策として登場(chǎng)しました。プロップドリルは、同じデータセットにアクセスする必要がある一連のコンポーネントがある場(chǎng)合に発生します。コンテキスト メカニズムにより、コンテキスト自體が最初の子孫である限り、コンポーネントは同じデータ セットを共有できます。

reactjs ドキュメントでは、テーマを保持するためのコンテキストが使用されます。他のコンポーネントがこの情報(bào)を必要とする可能性があるため、ドキュメントでは props 経由で値を渡すのではなく、コンテキストを使用してその情報(bào)を処理します。もう 1 つの例は、アプリケーションのレイアウトを保持するためのコンテキストの使用です。json-tool の例では、App.tsx は、すべてのアプリケーションで使用できる DefaultLayout コンテキストでアプリケーションをラップします。

この例のアプリ

次の例では、テーマ アプリが使用されます。これは、ユーザーが明るいテーマと暗いテーマを切り替えることができるアプリケーションです。このアプリは、reactjs 公式ドキュメントでも使用されています。このアプリケーションは、ライト テーマ モードとダーク テーマ モードを切り替えるシンプルなトグルで構(gòu)成されています。アプリケーションは非常にシンプルで、すべてを 1 つのファイルにプロットできます:

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

このアプリケーションには、アプリとページという 2 つの主要コンポーネントがあります。 App コンポーネントはメイン コンポーネントとして機(jī)能し、現(xiàn)在のテーマの狀態(tài) (「明るい」または「暗い」のいずれか) が含まれます。また、テーマをライト モードとダーク モードの間で切り替えるボタンも含まれています。 Page コンポーネントは App の子であり、テーマ コンテキストを使用して現(xiàn)在のテーマを表示します。 App コンポーネントのボタンは単純なトグル ボタンで、クリックするとテーマが切り替わり、それに応じてコンテキスト値が更新されます。

次のセクションでは、テスト用のコンポーネントのスライスについて説明します。

テスト用に點(diǎn)火する

通常、どのようなアプリケーションでも、どのような種類のテストを?qū)g行したいのか、どのスライスに取り組みたいのかに焦點(diǎn)を當(dāng)てる必要があります。たとえば、アプリケーション全體ではなく、単一のコンポーネントをターゲットにすることができます。この例では、Page コンポーネントから始めます。これをテストするには、test-double を使用する必要があります。

テストダブルはコンテキストに依存するため、アプリ構(gòu)造自體から取得され、それを変更するにはコンテキスト內(nèi)の値も変更する必要があります。

テストダブルス

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 でデフォルトのテーマに設(shè)定されている場(chǎng)合、このテストは期待どおりに合格します。この最初の例も同様にテストすることもできますが、ダーク テーマに興味がある 2 番目のテストで物事が面白くなります。ダークテーマに入るには、reactjs コンテキストに依存していることを考慮して、テストダブルの使用を開始する必要があります。 2 番目のテストでは、vi.mocked だけでなく vi.mock もミックスに加えます。 2 番目に作成するテストでは、最初のテストも変更する必要があることに注意してください。

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

両方のテスト ケースは、アプリケーションをテストするために偽物を使用しています。コンテキストから返されるデータを変更すると、テストも変更されます。ここでの注意點(diǎn)は次のとおりです。

• 私たちは、「自分が所有していないものを嘲笑するな」原則を強(qiáng)制するreactjsコンテキストを嘲笑しています
• モックを使用する必要があるため、テストはより冗長(zhǎng)になります
• 私たちが作成した 2 つのテストは、アプリケーションとのユーザーの対話を反映していません。トグルボタンを押すとテーマが変わることがわかっています。

このセクションで使用されている完成したコードは GitHub で入手できます

テストダブルなし

次のアプローチは、アプリケーションに埋め込まれたコンテキストを、分離したりテストダブルを使用したりせずに使用することです。 TDD でこのアプローチを採(cǎi)用すると、ユーザーがどのように動(dòng)作するかをシミュレートする非常に単純なテストから始めることができます。

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

次に 2 番目のテストに続いて、デフォルトでライト テーマを設(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()
  })
})

この戦略の注意點(diǎn):

• テストダブルは必要ありません。テストのコードが少なくなります
• テストの動(dòng)作は、ユーザーが実際のアプリケーションで行うことと一致します

このセクションで使用されている完成したコードは GitHub で入手できます

それぞれのアプローチの長(zhǎng)所と短所

このセクションでは、さまざまなプロパティに関する各アプローチの長(zhǎng)所と短所を説明します。

小道具へのリファクタリング

コンテキストにテストダブルを使用すると、この種の変更に対してテストが脆弱になります。 props を使用して useContext の使用をリファクタリングすると、動(dòng)作が失敗しない場(chǎng)合でもテストが自動(dòng)的に失敗します。テストダブルを使用しないオプションを使用すると、その意味でのリファクタリングがサポートされます。

カスタムコンテキストの作成

reactjs からのコンテキスト プロバイダーに直接依存するのではなく、カスタム コンテキストを使用しても同じことが起こります。テストダブルを使用せずにオプションを使用すると、リファクタリングが有効になります。

結(jié)論

このガイドでは、テストダブルを必要とせずにコンテキストに依存するコンポーネントをテストする方法を検討し、テストをより単純にして実際のユーザーの操作に近づけ、各アプローチの長(zhǎng)所と短所を?qū)澅趣丹护蓼筏?。可能な限り、ユーザー インタラクションを反映した単純なアプローチに従う必要があります。ただし、テストダブルが必要な場(chǎng)合は、テストコードの保守性を考慮して使用する必要があります。簡(jiǎn)単なテストを行うことで、本番コードで自信を持ってリファクタリングできるようになります。

リソース

• カスタムコンテキストの作成
• リファクタリング カタログ
• vitest を使用してモジュールの特定の部分をモックする方法を見つけるために使用されました
• 型の問題を修正する方法を見つけるために使用されました
• ライブラリ userEvent のテスト

次のステップ

• 複數(shù)のコンテキストまたはネストされたプロバイダーを含む、より複雑なシナリオをテストしてみてください。
• このガイドではモックを避けていますが、モックが必要な場(chǎng)合もあります。これらのシナリオ向けの高度なモック手法を検討してください。

これらの手順に従うことで、テスト スキルを継続的に向上させ、React アプリケーションがリファクタリングに対応できるようにすることができます。

以上がReactJS コンテキストのテスト - テストダブルのガイドの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。