Testen des ReactJS-Kontexts – Eine Anleitung mit Test-Doubles

In diesem Beitrag werde ich meinen Denkprozess zum Testen von React-Komponenten, die auf dem Kontext basieren, mithilfe der Testbibliothek durchgehen. Mein Ziel ist es, einen anderen Ansatz zum Testen dieser Komponenten zu erkunden und die Vor- und Nachteile der Verwendung von Mocks im Vergleich zum Testen ohne Mocks des Kontexts zu untersuchen. Wir werden untersuchen, wie sich jeder Ansatz auf die Zuverlässigkeit der Tests auswirkt, und ich werde Einblicke darüber geben, wann und warum eine Methode in realen Anwendungen möglicherweise vorteilhafter ist als die andere.

Was Sie wissen sollten

• Wofür ReactJS verwendet wird (wahrscheinlich haben Sie bereits einige Apps geschrieben)
• Was ist vitest

Was ist Reaktionskontext?

Der ReactJS-Kontext entstand als Lösung für ein häufiges Problem in der Struktur von ReactJS-Komponenten: das Bohren von Propellern. Beim Prop Drilling handelt es sich um eine Kette von Komponenten, die auf denselben Datensatz zugreifen müssen. Der Kontextmechanismus ermöglicht es Komponenten, denselben Datensatz gemeinsam zu nutzen, solange der Kontext selbst der erste Nachkomme ist.

In der ReactJS-Dokumentation wird der Kontext zum Halten des Themas verwendet. Da andere Komponenten diese Informationen möglicherweise benötigen, verwenden die Dokumente den Kontext, um dies zu verarbeiten, anstatt den Wert über Requisiten zu übergeben. Ein weiteres Beispiel ist die Verwendung von Kontext zum Speichern des Layouts der Anwendung. Im JSON-Tool-Beispiel umschließt App.tsx die Anwendung mit einem DefaultLayout-Kontext, der für die gesamte Anwendung verfügbar ist.

Die App für dieses Beispiel

Für das folgende Beispiel wird die Theme-App verwendet. Es handelt sich um eine Anwendung, mit der Benutzer zwischen hellen und dunklen Themen wechseln können. Die App wird auch in der offiziellen Dokumentation von ReactJS verwendet. Diese Anwendung besteht aus einem einfachen Umschalter, der zwischen dem hellen Themenmodus und dem dunklen Themenmodus wechselt. Die Anwendung ist denkbar einfach und wir können alles in einer einzigen Datei darstellen:

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

In dieser Anwendung haben wir zwei Hauptkomponenten: App und Seite. Die App-Komponente dient als Hauptkomponente und enthält den Status für das aktuelle Theme, der entweder „hell“ oder „dunkel“ sein kann. Es enthält auch eine Schaltfläche, mit der Sie das Thema zwischen hellem und dunklem Modus umschalten können. Die Page-Komponente ist ein untergeordnetes Element von App und nutzt den Themenkontext, um das aktuelle Thema anzuzeigen. Die Schaltfläche in der App-Komponente ist eine einfache Umschalttaste, die beim Klicken das Thema wechselt und den Kontextwert entsprechend aktualisiert.

Im nächsten Abschnitt werden wir über das Aufteilen der Komponenten zum Testen sprechen.

Die Zündung zum Testen

Normalerweise müssen wir uns bei jeder Anwendung darauf konzentrieren, welche Art von Test wir durchführen möchten und welchen Teil wir in Angriff nehmen möchten. Beispielsweise könnten wir statt der gesamten Anwendung auf eine einzelne Komponente abzielen. In unserem Beispiel beginnen wir mit der Page-Komponente. Dazu müssen wir Test-Doubles verwenden, um es zu testen.

Das Test-Double ergibt sich aus der App-Struktur selbst, da es vom Kontext abhängt. Um ihn zu ändern, muss sich auch der Wert im Kontext ändern.

Test-Doppel

Um mit unserem Testansatz mit Kontext in ReactJS zu beginnen, beginnen wir mit dem Schreiben des ersten Tests:

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

Dieser Test wird wie erwartet bestanden, vorausgesetzt, dass das Lichtthema im ThemeContext als Standard festgelegt ist. Auch dieses erste Exemplar könnten wir noch Probe fahren, interessant wird es jedoch im zweiten Test, wenn wir uns für das düstere Thema interessieren. Um in das dunkle Thema einzusteigen, müssen wir mit der Verwendung von Test-Doubles beginnen, da wir dazu auf den ReactJS-Kontext angewiesen sind. Der zweite Test bringt sowohl den vi.mock als auch den vi.mocked in den Mix. Beachten Sie, dass für den zweiten zu schreibenden Test auch eine Änderung des ersten Tests erforderlich war.

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

Beide Testfälle verwenden nun eine Fälschung, um die Anwendung zu testen. Wenn wir die Rückgabedaten aus dem Kontext ändern, ändert sich auch der Test. Die Aufmerksamkeitspunkte hier sind:

• Wir verspotten den ReactJS-Kontext, der das Prinzip „Verspotte nicht, was du nicht besitzt“ verletzt.
• Der Test wird ausführlicher, da wir dazu Mocking verwenden müssen
• Die beiden Tests, die wir geschrieben haben, spiegeln nicht die Benutzerinteraktion mit der Anwendung wider. Wir wissen, dass sich das Thema ändert, wenn die Umschalttaste gedrückt wird.

Der in diesem Abschnitt verwendete vollständige Code ist auf GitHub verfügbar

Ohne Testdoppel

Der nächste Ansatz besteht darin, den in unsere Anwendung eingebetteten Kontext zu verwenden, ohne ihn zu isolieren oder ein Test-Double zu verwenden. Wenn wir diesen Ansatz mit TDD verfolgen, können wir mit einem sehr einfachen Test beginnen, der simuliert, wie sich der Benutzer verhalten wird:

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

Dann folgt der zweite Test, bei dem wir das Lichtthema standardmäßig festlegen möchten:

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

und zu guter Letzt der Themenwechsel:

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

Hinweise zu dieser Strategie:

• Test-Doubles sind nicht erforderlich, dadurch ist der Test mit weniger Code erforderlich
• Das Verhalten des Tests entspricht dem, was der Benutzer in der realen Anwendung tun wird

Der in diesem Abschnitt verwendete vollständige Code ist auf GitHub verfügbar

Vor- und Nachteile jedes Ansatzes

In diesen Abschnitten gehen wir auf die Vor- und Nachteile jedes Ansatzes in Bezug auf verschiedene Eigenschaften ein.

Refactoring zu Requisiten

Die Verwendung eines Test-Doubles für den Kontext macht den Test für diese Art von Änderung anfällig. Die Umgestaltung der Verwendung von useContext mit Requisiten führt automatisch dazu, dass der Test fehlschlägt, selbst wenn das Verhalten dies nicht tut. Die Verwendung der Option, die keine Test-Doubles verwendet, unterstützt Refactoring in diesem Sinne.

Erstellen eines benutzerdefinierten Kontexts

Das Gleiche gilt für die Verwendung eines benutzerdefinierten Kontexts, anstatt sich direkt auf den Kontextanbieter von ReactJS zu verlassen. Die Verwendung der Option ohne Test-Doubles ermöglicht Refactoring.

Abschluss

In diesem Leitfaden haben wir untersucht, wie Komponenten getestet werden können, die auf dem Kontext basieren, ohne dass Testverdoppelungen erforderlich sind. Dadurch werden die Tests einfacher, näher an echten Benutzerinteraktionen und werden die Vor- und Nachteile der einzelnen Ansätze gegenübergestellt. Wann immer möglich, sollte der einfache Ansatz verwendet werden, der die Benutzerinteraktion widerspiegelt. Wenn jedoch Test-Doubles erforderlich sind, sollten diese verwendet werden, um die Wartbarkeit des Testcodes zu gewährleisten. Ein einfacher Test ermöglicht ein sicheres Refactoring im Produktionscode.

Ressourcen

• Einen benutzerdefinierten Kontext erstellen
• Der Refactoring-Katalog
• Wird verwendet, um herauszufinden, wie man einen bestimmten Teil eines Moduls mit vitest verspottet
• Wird verwendet, um herauszufinden, wie man Typprobleme behebt
• Benutzerereignis der Testbibliothek

Nächste Schritte

• Testen Sie komplexere Szenarien mit mehreren Kontexten oder verschachtelten Anbietern.
• Während wir in diesem Leitfaden Verspottungen vermieden haben, gibt es Fälle, in denen Verspottungen notwendig sind. Entdecken Sie fortgeschrittene Spotttechniken für diese Szenarien.

Indem Sie diese Schritte befolgen, können Sie Ihre Testfähigkeiten weiter verbessern und sicherstellen, dass Ihre React-Anwendungen für Refactoring offen sind.

Das obige ist der detaillierte Inhalt vonTesten des ReactJS-Kontexts – Eine Anleitung mit Test-Doubles. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!