PricingLoginStart free
Flutter Mobile Development · 课时

使用 bloc_test 和 Mocktail 测试 BLoC

使用 bloc_test 断言和模拟依赖，为 bloc 编写确定性的单元测试。

第 4 / 4 课13 个步骤

使用 bloc_test 和 Mocktail 测试 BLoC 是 CoddyKit 上的免费 Flutter Mobile Development 课时。 这是第 4 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 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.

免费开始

用 AI 导师学习 Dart — 免费

在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。

课程
22
课程
88
免费开始学习查看完整课程

常见问题解答

「使用 bloc_test 和 Mocktail 测试 BLoC」课时是免费的吗？

是的 — 「使用 bloc_test 和 Mocktail 测试 BLoC」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Flutter Mobile Development 课程的其余内容，请升级到 CoddyKit PRO。 Flutter Mobile Development 课程共包含 4 节课。

「使用 bloc_test 和 Mocktail 测试 BLoC」这节课中我会学到什么？

使用 bloc_test 断言和模拟依赖，为 bloc 编写确定性的单元测试。 你通过在浏览器中直接运行的动手代码来练习 Flutter Mobile Development，全天候 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