0Pricing
Flutter Mobile Development · Lezione

Test dei BLoC con bloc_test e Mocktail

Scriva unit test deterministici per i bloc usando le aspettative di bloc_test e dipendenze simulate.

Test dei BLoC con bloc_test e Mocktail è una lezione Flutter Mobile Development gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Flutter Mobile Development, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Flutter Mobile Development include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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.

Domande Frequenti

La lezione «Test dei BLoC con bloc_test e Mocktail» è gratuita?

Sì — il testo completo di «Test dei BLoC con bloc_test e Mocktail» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Flutter Mobile Development, passa a CoddyKit PRO. Il corso Flutter Mobile Development include 4 lezioni in totale.

Cosa imparerò in «Test dei BLoC con bloc_test e Mocktail»?

Scriva unit test deterministici per i bloc usando le aspettative di bloc_test e dipendenze simulate. Eserciti Flutter Mobile Development con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Flutter Mobile Development?

Non è richiesta alcuna esperienza precedente. Flutter Mobile Development su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Test dei BLoC con bloc_test e Mocktail»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Flutter Mobile Development?

Sì. Ogni lezione Flutter Mobile Development include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Eventi, stati e scelta tra Cubit e Bloc
  2. Trasformatori di stream e debounce degli eventi in BLoC
  3. Persistenza dello stato con HydratedBloc
  4. Test dei BLoC con bloc_test e Mocktail
← Torna a Flutter Mobile Development