| name | provider-tests |
| description | Use when adding or updating FlClash Riverpod provider tests, notifier tests, or state-management tests in this repository. |
Provider Tests
When To Use
Use this for tests under test/providers/ or any change that validates Riverpod providers, generated notifiers, app state defaults, or provider interactions.
For broader test expansion, pair this with .agents/rules.md and .agents/commands.md.
Workflow
-
Read the provider under test and its generated public API before writing assertions.
-
Use ProviderContainer directly when no widget tree is needed.
-
Dispose containers in teardown or with addTearDown(container.dispose).
-
Prefer generated notifier APIs over implementation details. Generated update() takes a callback:
notifier.update((state) => newValue);
-
Mock external dependencies with mocktail; register fallback values for freezed params used with any().
-
Keep tests focused on behavior: defaults, state transitions, persistence boundaries, and side effects.
-
Run the narrowest relevant test first:
flutter test test/providers/
Pitfalls
- Do not use
dart test; FlClash models and provider tests may depend on Flutter types.
- Re-check source defaults before asserting them; provider defaults can drift.
- If async provider timing matters, wait on provider futures or state changes instead of fixed sleeps.
