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:
dart
```
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:
bash
```
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.