- Home
- Skills
- Reactive
- Data Client
- Data Client React Testing
data-client-react-testing_skill
- TypeScript
2k
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill reactive/data-client --skill data-client-react-testing- SKILL.md5.5 KB
Overview
This skill provides utilities and patterns for testing @data-client/react code with renderDataHook and related helpers. It focuses on Jest unit tests for hooks and components, offering fixture-driven state, interceptors, and optional HTTP mocking with nock. The goal is reliable, deterministic tests for REST/GraphQL/SSE hooks, mutations, and manager middleware.
How this skill works
Use renderDataHook to mount hooks that rely on @data-client/react and supply initialFixtures to populate store state synchronously. Add resolverFixtures to intercept subsequent requests and return mock responses or transforms. For full HTTP-level tests, use nock to stub network endpoints and assert request behavior. The renderer returns controller access, cleanup utilities, and wait helpers to coordinate async operations.
When to use it
- Unit testing hooks that call resources (useSuspense, useController, etc.)
- Component tests that need a DataProvider-backed store
- Testing mutations and verifying created/updated entities without a real backend
- Simulating error responses and delay conditions
- Validating manager middleware behavior and side effects
Best practices
- Prefer initialFixtures for predictable initial state instead of mocking internals
- Use resolverFixtures for dynamic responses and to test mutation callbacks
- Test both success and error paths, including delayed responses
- Use nock only when exercising actual network request definitions
- Keep tests organized by environment: .node.test, .native.test, or regular .test files
Example use cases
- Render useSuspense(ArticleResource.get) with initialFixtures and assert returned data fields
- Simulate creating a todo via controller.fetch(TodoResource.getList.push) and assert assigned id from resolverFixtures
- Render a component inside DataProvider with initialFixtures and assert rendered list items
- Stub a third-party API with nock and call the resource directly to validate HTTP integration
- Attach a mock manager to renderDataHook and assert middleware is invoked during fetch
FAQ
Provide getInitialInterceptorData or resolverFixtures that compute responses based on prior calls to mimic evolving server state.
When should I use nock instead of fixtures?
Use nock when you want to exercise the actual HTTP layer or validate request shapes; use fixtures/resolvers for faster, isolated unit tests without network I/O.