원클릭으로
dart-flutter-testing
When writing unit/widget tests for repositories, DTO parsing, and BLoCs using Given/When/Then and mocked I/O.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
When writing unit/widget tests for repositories, DTO parsing, and BLoCs using Given/When/Then and mocked I/O.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Prepares Dart and Flutter packages for publication to pub.dev, ensuring all metadata, documentation, and requirements are met. Use when preparing to publish a package, updating package metadata, or reviewing package publication readiness.
Use when working with opencode_api package to send prompts to opencode server and interpret the message response structure (text, reasoning, tool parts).
Runs pana analysis on Dart packages, identifies scoring issues, and suggests fixes to achieve higher pub scores. Use when improving package quality, preparing for pub.dev publication, or when pana score issues are mentioned.
Library-agnostic Flutter/Dart code review checklist covering Widget best practices, state management patterns (BLoC, Riverpod, Provider, GetX, MobX, Signals), Dart idioms, performance, accessibility, security, and clean architecture.
Updates pinned package dependencies for Dart and Flutter project templates. Use when adding/removing packages from the allowlist or updating dependency versions across Flutter channels (main/beta/stable).
Apply secure coding practices to prevent common security vulnerabilities including information leakage, injection attacks, authentication flaws, and insecure error handling. Use when writing authentication code, handling errors, processing user input, or when security review is needed.
| name | dart-flutter-testing |
| description | When writing unit/widget tests for repositories, DTO parsing, and BLoCs using Given/When/Then and mocked I/O. |
test/ structure aligned with the source layout so ownership and coverage are obvious.Prefer tests around:
Example (DTO parsing):
import 'package:flutter_test/flutter_test.dart';
void main() {
test('OrderDto parses expected payload', () {
final dto = OrderDto.fromMap({
'id': '1',
'createdAt': '2026-01-01T00:00:00.000Z',
'timeout_ms': 0,
'status': 'unknown',
});
expect(dto.id, '1');
});
}
Use mocktail (or your project's standard) to isolate I/O:
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
class _RemoteMock extends Mock implements IOrdersRemoteDataSource {}
void main() {
test('repository maps failures to typed exceptions', () async {
final remote = _RemoteMock();
when(() => remote.fetchOrders()).thenThrow(Exception('boom'));
final repo = OrdersRepository(remote: remote);
expect(repo.getOrders(), throwsA(isA<NetworkException>()));
});
}
Prefer bloc_test and keep expectations explicit:
import 'package:bloc_test/bloc_test.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
class _RepoMock extends Mock implements IOrdersRepository {}
void main() {
blocTest<OrdersBloc, OrdersState>(
'emits Loading then Loaded',
build: () {
final repo = _RepoMock();
when(() => repo.getOrders()).thenAnswer((_) async => const []);
return OrdersBloc(repository: repo);
},
act: (bloc) => bloc.add(const OrdersStartedEvent()),
expect: () => [const OrdersLoadingState(), const OrdersLoadedState(orders: [])],
);
}
If event ordering is part of the expected behavior, separate event dispatches in act:
act: (bloc) async {
bloc.add(const FirstEvent());
await Future<void>.delayed(Duration.zero);
bloc.add(const SecondEvent());
},
Widget tests should verify:
Prefer one scenario per test for easier failure diagnosis.
package:checks for AssertionsFor clearer failure messages and a fluent API, prefer package:checks over matcher:
import 'package:checks/checks.dart';
import 'package:flutter_test/flutter_test.dart';
test('validates value', () {
final value = 42;
check(value).equals(42);
check(value).isGreaterThan(0);
});
setUp/tearDown inside group(...) blocks.flutter test --test-randomize-ordering-seed random
golden) so they can run separately.--update-goldens only in explicit golden update workflows.flutter test --tags golden
flutter test --tags golden --update-goldens
Use integration_test for critical user flows (e.g., login, checkout).
import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';
import 'package:my_app/main.dart' as app;
void main() {
IntegrationTestWidgetsFlutterBinding.ensureInitialized();
testWidgets('full login flow', (tester) async {
app.main();
await tester.pumpAndSettle();
await tester.enterText(find.byKey(const Key('email_field')), 'user@example.com');
await tester.tap(find.byKey(const Key('login_btn')));
await tester.pumpAndSettle();
expect(find.text('Welcome back!'), findsOneWidget);
});
}