I have a bloc event, and I'm writing test for it, my event have one case that will add another event, that I don't want to include in test because I'm focusing on one event, so I have tried multiple solutions, but no one of them worked.

1. first i have tried to mock .add function, but i found that i can't stub it because its not a function so get this Bad state: No method stub was called from within when(). Was a real method called, or perhaps an extension method?.

when(manageMissionPointBloc.add(const ManageMissionPointEvent.reconfigureBloc())).thenAnswer((_) => null);

2. the second thing i tried to do it to override add event for this specific event, but i found that i can't remove a listener because the stream in private.

manageMissionPointBloc.on<ManageMissionPointEvent>((event, emit) async {
          if (event is EventReconfigureBloc) {
            await manageMissionPointBloc.close();
            return;
          }
        });

3. finally, I can't mock bloc itself because I have the concrete implementation to test it, so I tried this too using mockito.

So does this is possible, or calling another event from an event is wrong in the first place?

NOTE: I have multiple events each one can call 'reconfigureBloc' in some cases, so it's not ideal to add cases of 'reconfigureBloc' events in each event that i'm writing test for, while it's already well tested.

I have a bloc event, and I'm writing test for it, my event have one case that will add another event, that I don't want to include in test because I'm focusing on one event, so I have tried multiple solutions, but no one of them worked.

1. first i have tried to mock .add function, but i found that i can't stub it because its not a function so get this Bad state: No method stub was called from within when(). Was a real method called, or perhaps an extension method?.

when(manageMissionPointBloc.add(const ManageMissionPointEvent.reconfigureBloc())).thenAnswer((_) => null);

2. the second thing i tried to do it to override add event for this specific event, but i found that i can't remove a listener because the stream in private.

manageMissionPointBloc.on<ManageMissionPointEvent>((event, emit) async {
          if (event is EventReconfigureBloc) {
            await manageMissionPointBloc.close();
            return;
          }
        });

3. finally, I can't mock bloc itself because I have the concrete implementation to test it, so I tried this too using mockito.

So does this is possible, or calling another event from an event is wrong in the first place?

NOTE: I have multiple events each one can call 'reconfigureBloc' in some cases, so it's not ideal to add cases of 'reconfigureBloc' events in each event that i'm writing test for, while it's already well tested.

• flutter
• dart
• unit-testing
• bloc
• flutter-bloc

1 Answer 1

(...) my event have one case that will add another event, that I don't want to include in test because I'm focusing on one event, so I have tried multiple solutions, but no one of them worked.

You are testing handling of a particular event in your bloc. Because the first event is handled with adding another event, you cannot really test just the first event. This second event is a side effect of what you're testing and you can't really omit this.

Of course, you can pass some @visibleForTesting flag that will make the bloc not emit this, but then you are not really testing the actual behavior of your bloc, but the one altered for the test.

I'd say that you should treat the whole flow of events and states resulting from adding the first event as a whole in your test.

There was an issue asking the same question on the bloc repository and Felix (bloc's author) responded. See the issue for the whole picture.

At the end of the day the bloc takes events as input and emits states so your test should just verify that when event x is added, state y is emitted. Whether the bloc adds more events internally or not is just an implementation detail and does not impact the behavior.

— [bloc_test] How to test a bloc that adds event to itself

Personally I wouldn't say that adding events from handler of another event is very wrong, it depends on the use-case, you can do that, but there's this testing caveat that you've just encountered.