ワンクリックで
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);
});
}