0Pricing
Flutter Mobile Development · レッスン

bloc_testとMocktailによるBLoCのテスト

bloc_testの期待値とモック化した依存関係を使い、決定的なBLoCの単体テストを作成します。

「bloc_testとMocktailによるBLoCのテスト」はCoddyKit上の無料Flutter Mobile Developmentレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはFlutter Mobile Development学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why BLoCs Need Deterministic Tests

A BLoC is a pure state machine: it takes events in and emits a predictable sequence of states out. That makes it the most testable layer of a Flutter app.

A good bloc test answers one question: given this starting state and these events, exactly which states get emitted, in what order?

  • Deterministic means the same input always produces the same output sequence.
  • Sources of non-determinism to eliminate: real network calls, DateTime.now(), random values, and timers.

We solve this with two packages: bloc_test for the test harness and mocktail for faking dependencies.

Setting Up the Test Dependencies

Add the test tooling to the dev_dependencies section of pubspec.yaml. None of these ship in your production bundle.

  • bloc_test provides the blocTest helper.
  • mocktail creates mocks with no code generation.
  • test gives you group, setUp, and expect.

Mocktail is preferred over Mockito here because it needs no build_runner step and works cleanly with null safety.

dev_dependencies:
  bloc_test: ^9.1.7
  mocktail: ^1.0.4
  test: ^1.25.0

The BLoC Under Test

Here is the BLoC we will test. A WeatherBloc depends on a WeatherRepository abstraction. On a WeatherRequested event it emits a loading state, then either a success or failure state.

Notice the dependency is injected through the constructor. This is the key design choice that makes the BLoC testable: we can pass in a fake repository instead of one that hits the network.

class WeatherBloc extends Bloc<WeatherEvent, WeatherState> {
  WeatherBloc(this._repository) : super(WeatherInitial()) {
    on<WeatherRequested>(_onRequested);
  }

  final WeatherRepository _repository;

  Future<void> _onRequested(
    WeatherRequested event,
    Emitter<WeatherState> emit,
  ) async {
    emit(WeatherLoading());
    try {
      final weather = await _repository.fetch(event.city);
      emit(WeatherSuccess(weather));
    } catch (_) {
      emit(WeatherFailure());
    }
  }
}

Creating a Mock with Mocktail

To isolate the BLoC, we replace the real repository with a mock. With Mocktail you simply extend Mock and implement the abstraction.

  • No annotations, no generated .mocks.dart files.
  • The mock starts with every method stubbed to return null until you tell it otherwise.

You then control its behaviour per test using when(...).thenAnswer(...).

import 'package:mocktail/mocktail.dart';

class MockWeatherRepository extends Mock
    implements WeatherRepository {}

class FakeWeather extends Fake implements Weather {}

Stubbing Return Values

Inside a test, configure the mock before acting. Use thenAnswer for asynchronous methods that return a Future, and thenThrow to simulate an error path.

  • thenAnswer((_) async => value) returns a resolved Future.
  • thenThrow(Exception()) makes the call fail, exercising your catch block.

This is how you force the exact branch you want without any real I/O.

// Success path stub
when(() => repository.fetch('London'))
    .thenAnswer((_) async => const Weather(temp: 14, city: 'London'));

// Failure path stub
when(() => repository.fetch('London'))
    .thenThrow(Exception('network down'));

The blocTest Helper Anatomy

The blocTest function from bloc_test wires up the whole flow. Its core parameters are:

  • build: returns a fresh BLoC instance for each run.
  • act: dispatches one or more events into that BLoC.
  • expect: the ordered list of states that should be emitted, excluding the initial state.

The build callback runs anew every test, guaranteeing a clean slate and no shared state between cases.

blocTest<WeatherBloc, WeatherState>(
  'emits [Loading, Success] when fetch succeeds',
  build: () {
    when(() => repository.fetch(any()))
        .thenAnswer((_) async => const Weather(temp: 14, city: 'London'));
    return WeatherBloc(repository);
  },
  act: (bloc) => bloc.add(const WeatherRequested('London')),
  expect: () => const [
    WeatherLoading(),
    WeatherSuccess(Weather(temp: 14, city: 'London')),
  ],
);

Equatable Makes expect Work

The expect list compares emitted states to your expected states using ==. Plain Dart classes compare by identity, so two different WeatherSuccess instances would never be equal and your test would fail confusingly.

Override value equality with the equatable package. List the fields in props and instances with the same values compare as equal.

abstract class WeatherState extends Equatable {
  const WeatherState();
  @override
  List<Object?> get props => [];
}

class WeatherSuccess extends WeatherState {
  const WeatherSuccess(this.weather);
  final Weather weather;
  @override
  List<Object?> get props => [weather];
}

Testing the Failure Path

Robust tests cover errors, not just the happy path. Stub the dependency to throw, then assert the BLoC emits the failure state instead of crashing.

This proves your try/catch in the handler actually converts exceptions into a user-facing error state.

blocTest<WeatherBloc, WeatherState>(
  'emits [Loading, Failure] when fetch throws',
  build: () {
    when(() => repository.fetch(any()))
        .thenThrow(Exception('network down'));
    return WeatherBloc(repository);
  },
  act: (bloc) => bloc.add(const WeatherRequested('London')),
  expect: () => const [
    WeatherLoading(),
    WeatherFailure(),
  ],
);

registerFallbackValue for any()

Mocktail's any() matcher lets you stub a call regardless of the argument. But for custom types Mocktail cannot construct a placeholder, so it throws at registration time.

Fix this by registering a Fake instance once in setUpAll. Built-in types like String and int never need this; only your own classes do.

setUpAll(() {
  // Required before using any<Weather>() in stubs
  registerFallbackValue(FakeWeather());
});

Verifying Interactions

Beyond asserting emitted states, you often want to confirm the BLoC actually called its dependency the right number of times. Use verify in the verify callback of blocTest, which runs after expect.

  • verify(() => mock.method()).called(1) asserts exactly one call.
  • verifyNever(...) asserts a call never happened.

This catches bugs where the right state is emitted but for the wrong reason.

blocTest<WeatherBloc, WeatherState>(
  'calls repository exactly once',
  build: () {
    when(() => repository.fetch(any()))
        .thenAnswer((_) async => const Weather(temp: 14, city: 'London'));
    return WeatherBloc(repository);
  },
  act: (bloc) => bloc.add(const WeatherRequested('London')),
  verify: (_) {
    verify(() => repository.fetch('London')).called(1);
  },
);

Controlling Time with seed and skip

Two more blocTest parameters give you fine control:

  • seed: provides a starting state, so you can test a transition from any point, not just the initial state.
  • skip: ignores the first N emitted states, useful when you only care about the final one.
  • wait: a Duration to let debounced or delayed events settle before assertions run.

Use seed to test event handlers in isolation without replaying the entire history.

blocTest<CounterBloc, int>(
  'emits [11] from a seeded state of 10',
  build: () => CounterBloc(),
  seed: () => 10,
  act: (bloc) => bloc.add(Increment()),
  expect: () => const [11],
);

Quick Check

A test stubs repository.fetch(any()) where fetch takes a custom Weather argument, and the test crashes at setup with a fallback-value error before any state is emitted. What is the correct fix?

Recap: Deterministic BLoC Testing

You now have a repeatable recipe for testing BLoCs:

  • Inject dependencies through the constructor so they can be swapped for mocks.
  • Create mocks by extending Mock implements with Mocktail; no code generation needed.
  • Stub behaviour with thenAnswer for success and thenThrow for failure paths.
  • Use blocTest with build / act / expect to assert the exact ordered states.
  • Make expect reliable with Equatable value equality.
  • Register fallbacks with registerFallbackValue when matching custom types via any().
  • Confirm intent with verify, and control flow with seed, skip, and wait.

Cover both the happy and failure paths, and your BLoC layer becomes fully deterministic and regression-proof.

よくある質問

「bloc_testとMocktailによるBLoCのテスト」レッスンは無料ですか？

はい。「bloc_testとMocktailによるBLoCのテスト」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Flutter Mobile Developmentコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

「bloc_testとMocktailによるBLoCのテスト」で何を学びますか？

bloc_testの期待値とモック化した依存関係を使い、決定的なBLoCの単体テストを作成します。 ブラウザで直接実行するハンズオンコードでFlutter Mobile Developmentを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Flutter Mobile Developmentを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFlutter Mobile Developmentは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「bloc_testとMocktailによるBLoCのテスト」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFlutter Mobile Developmentレッスンでコードを書いて実行できますか？

はい。すべてのFlutter Mobile Developmentレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. イベント、状態、CubitとBlocの選択
  2. BLoCのストリーム変換とイベントのデバウンス
  3. HydratedBlocによる状態の永続化
  4. bloc_testとMocktailによるBLoCのテスト
← Flutter Mobile Developmentに戻る