testing
/testing
Pomaga pisać i recenzować testy we Flutter i Dart: jednostkowe, widżetów i golden, naprawiać niestabilne testy, dodawać pokrycie i wybierać między testami jednostkowymi a widżetów.
- Autor
- evanca ↗
- Repozytorium
- flutter-ai-rules ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 10.10.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 10.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Pomaga pisać i recenzować testy we Flutter i Dart: jednostkowe, widżetów i golden, naprawiać niestabilne testy, dodawać pokrycie i wybierać między testami jednostkowymi a widżetów.
Oryginalny opis (EN)
Use when writing or reviewing Flutter/Dart tests (unit, widget, golden), fixing flaky tests, adding coverage, or choosing between unit and widget tests.
Jak działa
- When to Use
- 1. Test Validity
- 2. Structure
- 3. Naming
- 4. Unit Tests vs Widget Tests
- 5. Widget Test Patterns
- 6. Mocking Best Practices
- 7. Test File Organization
Podgląd SKILL.md
---
name: testing
description: "Use when writing or reviewing Flutter/Dart tests (unit, widget, golden), fixing flaky tests, adding coverage, or choosing between unit and widget tests."
license: MIT
---
# Testing Skill
Write effective, meaningful Flutter and Dart tests that catch real regressions.
## When to Use
Use this skill when:
* Writing unit tests for business logic, repositories, or utility classes.
* Writing widget tests for UI components.
* Reviewing existing tests for correctness and coverage.
* Fixing flaky or false-positive tests.
* Deciding between unit tests, widget tests, and integration tests.
---
## 1. Test Validity
Before writing or accepting a test, ask:
> **"Can this test actually fail if the real code is broken?"**
- Avoid tests that only confirm mocked/fake behavior without exercising real logic.
- Avoid tests that confirm behavior guaranteed by the language or standard library.
- Every test must be capable of catching a real regression.
```dart
// BAD — tests the mock, not real logic
test('should return user', () {
when(() => repo.getUser()).thenReturn(fakeUser);
expect(repo.getUser(), fakeUser); // Only proves the mock works
});
// GOOD — tests the cubit's state transitions driven by the mock
blocTest<UserCubit, UserState>(
'should emit loaded state when getUser succeeds',
build: () {
when(() => repo.getUser()).thenAnswer((_) async => fakeUser);
return UserCubit(repo);
},
act: (cubit) => cubit.fetchUser(),
expect: () => [
const UserState(status: UserStatus.loading),
UserState(status: UserStatus.loaded, user: fakeUser),
],
);
```
---
## 2. Structure
Always use `group()` in test files. Name the group after the **class under test**:
```dart
group('Counter', () {
late Counter counter;
setUp(() {
counter = Counter();
});
test('value should start at 0', () {
expect(counter.value, 0);
});
test('should increment value by 1', () {
counter.increment();
expect(counter.value, 1);
});
});
```
Rules:
- Use `setUp` for shared object creation; use `tearDown` for cleanup (closing streams, controllers).
- Keep each test focused on one behavior.
- Nest `group()` blocks for sub-features when a class has many methods.
---
## 3. Naming
Name test cases using **"should"** to describe expected behavior:
```dart
test('should emit updated list when item is added', () { ... });
test('should throw ArgumentError when input is negative', () { ... });
```
---
## 4. Unit Tests vs Widget Tests
| Type | Target | Tools |
|---|---|---|
| **Unit test** | Pure Dart logic, repositories, cubits/blocs | `test`, `bloc_test`, `mocktail` |
| **Widget test** | Individual widgets, UI behavior, navigation | `flutter_test`, `WidgetTester` |
Default to **unit tests** for business logic. Use **widget tests** when verifying UI rendering, gesture handling, or widget interaction.
---
## 5. Widget Test Patterns
```dart
testWidgets('should display error message on failure', (tester) async {
await tester.pumpWidget(
MaterialApp(
home: BlocProvider<LoginCubit>.value(
value: mockLoginCubit,
child: const LoginView(),
),
),
);
// Simulate failure state
whenListen(
mockLoginCubit,
Stream.fromIterable([const LoginState(status: LoginStatus.failure, errorMessage: 'Invalid')]),
initialState: const LoginState(),
);
await tester.pump();
expect(find.text('Invalid'), findsOneWidget);
});
```
Rules:
- Wrap widgets in `MaterialApp` (or the app's root widget) to provide `MediaQuery`, `Directionality`, etc.
- Use `pump()` for a single frame or `pumpAndSettle()` when animations must complete.
- Prefer `find.byKey` over `find.text` for widgets that may have localized or dynamic text.
---
## 6. Mocking Best Practices
- Use `mocktail` for mocks (no code generation required).
- Call `registerFallbackValue()` in `setUpAll` for custom types passed to `any()`.
- Mock at the repository boundary, not at the HTTP/database layer.
```dart
class MockAuthRepository extends Mock implements AuthRepository {}
void main() {
setUpAll(() {
registerFallbackValue(FakeLoginRequest());
});
// ... tests
}
```
---
## 7. Test File Organization
```
test/
feature_a/
cubit/
feature_a_cubit_test.dart
view/
feature_a_view_test.dart
model/
feature_a_model_test.dart
```
- Mirror the `lib/` folder structure under `test/`.
- One test file per source file.
- Name test files `<source_file>_test.dart`.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · evanca/flutter-ai-rules | 100 | MIT |
| wrongstack/wrongstack | 100 | MIT |
| langwatch/langwatch | 100 | Apache-2.0 |
| mcouthon/agents | 100 | MIT |
| nteract/nteract | 100 | BSD-3-Clause |
| kettleofketchup/DraftForge | 100 | GPL-3.0 |
| TheBeardedBearSAS/claude-craft | 100 | MIT |
| fastrepl/anarlog | 100 | MIT |
| nvidia/nvcf | 100 | Apache-2.0 |
Migawka bazy z 28.10.2026 · wersja paczki a381145c5a39 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100flutter-test-strategy
Pomaga zdecydować, co testować w kodzie Flutter i Dart na której warstwie (unit, widget, golden, integration) oraz ustawić progi pokrycia. - 85flutter-core:flutter-testing-quality
Pisze testy aplikacji Flutter: jednostkowe, widgetów, integracyjne i golden, z mockami, pokryciem i profilowaniem w DevTools. - 100flutter-testing
Pomaga pisać i recenzować testy aplikacji Flutter z Riverpod, repozytoriami opartymi na Result i SDK za kontraktami: testy unit, widget z override providerów, golden oraz wybór między mockiem a fake. - 100flutter-testing
Pisze, naprawia, recenzuje i waliduje testy Flutter dla aplikacji, pakietów i wtyczek: unit, widget, integration, mocki MethodChannel, Mockito i mocktail, golden, MissingPluginException, pump i niestabilne testy. - 100flutter-testing
Pisze testy unit, widget, golden i integration dla projektów Flutter, wykrywając z pubspec.yaml, czy używany jest BLoC, Riverpod, Provider czy GetX, zanim napisze testy logiki biznesowej. - 100flutter-testing
Projektuje, pisze i przegląda testy jednostkowe, widgetów, golden i integracyjne we Flutterze: strategia testów, regresje, fake'i, asynchroniczny UI i przepływy end-to-end.