Testing
ShadCN UI components are well-designed and accessible. What they're not, by default, is performance-tested for your specific usage. A DataTable with 50 rows behaves differently than one with 50,000 rows. A Combobox with 100 options is fine; with 10,000 options, it depends on how
Next.js
Unit tests verify that individual functions and components work correctly.
Testing
End-to-end tests verify your whole application works together. Unit tests verify individual functions in isolation. Component tests sit between them: they mount a single React component in a real browser, let you interact with it, and assert on what the user actually sees. Cypress component testing brings the
Testing
Component-level accessibility testing is where you prevent accessibility bugs from ever reaching the browser. By testing at the unit and integration level — before a real page renders — you catch missing ARIA attributes, broken focus management, and silent live regions while the component code is right in front of you.
Test Automation
React Server Components (RSC) are a genuinely new primitive — they run only on the server, can be async, and never ship JavaScript to the browser. They're also one of the hardest things to unit-test in a Next.js application. The core problem: Jest runs in Node.js
Testing
React and Next.js have become the default stack for building multilingual web apps, with libraries like react-i18next, next-intl, and react-intl handling the heavy lifting. But a common mistake is writing no tests for the i18n layer itself — assuming that if translations load, everything works. This guide
GraphQL
Apollo Client components are hard to test without the right tools because they depend on a live GraphQL server. Apollo's MockedProvider lets you define expected operations and their responses, so you can test components in complete isolation. This guide covers the full spectrum: loading states, successful responses, errors,
react
React Router v7 uses Vite as its default build tool, which makes Vitest the natural testing choice — it reuses the same Vite config, understands import.meta.env natively, and runs 10–40x faster than Jest on Vite-based projects. This guide covers the full Vitest setup for a React Router
react
End-to-end tests for React Router v7 apps need to account for SSR hydration, client-side navigation, loader data rendering, and form action redirects. This guide sets up Playwright for a v7 app from scratch and covers every major testing scenario with working examples. Key Takeaways SSR hydration must
react
Migrating a Remix app to React Router v7 involves import path changes, API renames, and route config restructuring. The safest migration strategy writes tests against your Remix app first, then runs the same tests after migration to catch regressions. This post walks through the full test-first migration workflow. Key
react
Loaders and actions in React Router v7 are plain async functions. Testing them directly — without rendering any component — gives you fast, reliable, and surgical feedback. This post covers every scenario: happy paths, error responses, redirects, validation failures, and async mocking patterns using Vitest. Key Takeaways Test loaders and actions as
react
React Router v7 unified the React Router and Remix libraries into one package, introducing routes.ts, framework mode SSR, and new testing APIs. This guide covers how to test every layer of a v7 app — from individual loaders to full E2E flows — using Vitest, React Testing Library, and Playwright. Key