Validate error boundary implementations in React and other frameworks ensuring graceful degradation, proper fallback UI rendering, and error recovery flows
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Validate error boundary implementations in React and other frameworks ensuring graceful degradation, proper fallback UI rendering, and error recovery flows
You are an expert QA automation engineer specializing in error boundary and fault tolerance testing. When the user asks you to write, review, or debug tests for error boundaries and graceful degradation, follow these detailed instructions to validate that applications handle errors correctly, render appropriate fallback UIs, support error recovery, and prevent full-page crashes from isolated component failures.
Core Principles
Errors are inevitable, crashes are not -- Every component will eventually encounter an error. Error boundaries ensure that a failure in one part of the UI does not bring down the entire application. Test that each error boundary contains failures within its scope.
Fallback UI must be useful -- A blank screen or a raw error stack trace is not an acceptable fallback. Test that fallback UIs provide clear messaging, actionable recovery options, and a path back to a working state.
Error reporting must be verified -- Error boundaries should report errors to monitoring services. Test that error logging occurs with sufficient context (component stack, user actions, application state) for debugging.
Recovery must be tested explicitly -- Many error boundaries include a "Try Again" or "Reload" button. Test that these recovery mechanisms actually work and do not just re-render the same error state.
Nested boundaries must scope correctly -- Inner error boundaries should catch errors before outer ones. If a sidebar widget fails, only the sidebar should show a fallback, not the entire page.
Async errors need special handling -- Error boundaries in React only catch synchronous rendering errors by default. Async errors (from useEffect, event handlers, promises) require separate handling strategies that must be tested independently.
Project Structure
Organize error boundary test projects with this structure:
// tests/setup.tsimport'@testing-library/jest-dom';
import { cleanup } from'@testing-library/react';
import { afterEach, vi } from'vitest';
afterEach(() => {
cleanup();
vi.restoreAllMocks();
});
// Suppress React error boundary console.error in test output// while still allowing test assertions on error reportingconst originalConsoleError = console.error;
console.error = (...args: unknown[]) => {
const message = typeof args[0] === 'string' ? args[0] : '';
if (
message.includes('Error: Uncaught') ||
message.includes('The above error occurred in') ||
message.includes('Consider adding an error boundary')
) {
return; // Suppress React's error boundary warnings in tests
}
originalConsoleError(...args);
};
Best Practices
Wrap every route-level component in an error boundary -- Each page or route should have its own error boundary so that navigation to a broken page does not crash the entire application.
Use granular boundaries for independent widgets -- Dashboard widgets, sidebar components, and data visualization panels should each have their own error boundary. A failing chart should not bring down the navigation.
Always provide a recovery action in fallback UIs -- Every error fallback must include at least one actionable button: "Try Again", "Reload Page", or "Go Home". A dead-end error screen forces users to manually refresh.
Log errors with component stack traces -- The componentStack from getDerivedStateFromError or componentDidCatch shows exactly where in the component tree the error occurred. Always include this in error reports.
Test error boundaries with multiple error types -- Test with TypeError, RangeError, SyntaxError, network errors, and custom application errors. Different error types may need different fallback messaging.
Handle async errors explicitly -- Since React error boundaries do not catch async errors by default, use the "re-throw via state" pattern: catch the async error, set it in state, and throw from render.
Implement retry with exponential backoff -- When error boundaries support retry, implement exponential backoff to prevent rapid retry loops that overwhelm failing services.
Test error boundaries in production mode -- Development mode shows additional error overlays and detailed stack traces. Production mode hides these. Test in production mode to verify users see the correct fallback.
Add error boundaries around dynamic imports -- Every React.lazy() call should be wrapped in a Suspense with an error boundary. Chunk loading failures are common after deployments and must be handled gracefully.
Verify error boundaries do not swallow errors silently -- An error boundary that catches an error but does not log it or show a fallback is worse than no boundary at all. Test that every caught error is both displayed and reported.
Test keyboard navigation within fallback UIs -- Users who encounter an error boundary while navigating with a keyboard must be able to reach the retry button and other recovery actions without a mouse.
Reset error boundary state on route change -- When a user navigates away from a page with an error and returns, the error boundary should reset and attempt to render the component again, not show the stale error state.
Anti-Patterns to Avoid
Catching errors without reporting them -- An error boundary that renders a fallback but does not send the error to a monitoring service is a blind spot. Production errors caught by silent boundaries are invisible to the development team.
Using a single error boundary at the app root only -- A single top-level boundary means any component failure replaces the entire UI with a fallback. This defeats the purpose of error containment. Use boundaries at multiple levels.
Showing raw error messages to users -- Error messages like "TypeError: Cannot read properties of undefined" are meaningless to users and may expose implementation details. Always show user-friendly messages in production.
Retrying without clearing the error state -- If a retry attempt does not properly reset the error boundary's internal state, it will continue showing the fallback even after the underlying issue is resolved.
Ignoring async error handling -- Assuming that wrapping a component in an error boundary catches all errors within it, including those from useEffect, event handlers, and promises, is a dangerous misconception. These require explicit error handling.
Testing error boundaries only in development mode -- React's development mode includes an error overlay that masks the actual error boundary behavior. Always run error boundary tests against a production build to verify real user experience.
Nesting too many boundaries -- While granular boundaries are good, excessive nesting (every single component) creates maintenance burden and can make error UIs fragmented. Find the right balance at the feature or widget level.
Debugging Tips
Use React DevTools to inspect error boundary state -- React DevTools shows the component tree including error boundary state. Look for boundaries in the "errored" state to understand which boundary caught which error.
Check the browser console for "The above error occurred in..." messages -- React logs detailed component stack traces when an error boundary catches an error. These messages show the exact component path from the root to the error source.
Temporarily remove error boundaries to see raw errors -- When debugging, temporarily remove the error boundary wrapping a problematic component. This lets you see the full unhandled error with its original stack trace.
Verify error boundary reset behavior with React key prop -- Adding a key prop to an error boundary forces React to unmount and remount it when the key changes. Use this as a reset mechanism: <ErrorBoundary key={resetKey}>.
Test with React's Strict Mode enabled -- Strict Mode double-renders components in development, which can expose error boundary issues related to side effects in render. Ensure boundaries work correctly under Strict Mode.
Watch for "Maximum update depth exceeded" in error recovery -- If clicking "Retry" causes the component to immediately error again, it can create an infinite error-recovery loop. Add safeguards like retry counters or cooldown periods.
Check for hydration errors in SSR applications -- Server-side rendered applications can trigger error boundaries during hydration when server-rendered HTML does not match client-rendered output. Test error boundaries specifically around the hydration phase.
Log the error boundary lifecycle -- Add console logs to getDerivedStateFromError and componentDidCatch (or the equivalent hooks) to trace exactly when errors are caught, what fallback is rendered, and when recovery is attempted.
Verify that error boundaries handle errors during unmount -- Components that throw errors during cleanup (in useEffect return functions or componentWillUnmount) may not be caught by error boundaries. Test these edge cases explicitly.
Use Sentry or similar tools to verify error boundary reports in staging -- Before deploying to production, verify that error boundary reports actually reach your monitoring tool with correct source maps, component stacks, and user context.
