feat(bloc_test): testBlocFakeAsync - fire all asynchronous events without actually needing to wait for real time to elapse

[PankovSerge]

Status

READY

Breaking Changes

NO

Description

This pull request aims to address the issue of slow test execution in complex test cases involving multiple events with throttleTime, debounceTime, or similar delays in the current implementation of bloc_test.

To tackle this problem, this pull request introduces a new function called testBlocFakeAsync. This new function is built around FakeAsync which provides a way to simulate and fire all asynchronous events that are scheduled for that time period without actually requiring the test to wait for real time to elapse.

Example

  fakeAsyncBlocTest<DebounceCounterBloc, int>(
        'emits [2] when CounterEvent.increment '
        'is added twice and skip: 1',
        build: () => DebounceCounterBloc(),
        act: (bloc, fakeAsync) async {
          bloc.add(CounterEvent.increment);
          fakeAsync.elapse(const Duration(milliseconds: 305));
          bloc.add(CounterEvent.increment);
        },
        skip: 1,
        wait: const Duration(milliseconds: 300),
        expect: () => const <int>[2],
      );

Comparison

bloc_bloc_test_test.dart average execution time:

bloc_fake_async_bloc_test_test.dart - same test cases, but with testBlocFakeAsync:

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[mugbug]

This method duplicates a lot of code that can be found on testBloc. What about refactoring both to share as much code as possible so maintenance is simpler?

[PankovSerge]

@tenhobi @mugbug there's a few reasons to not unify the code:

1. Breaking change
2. fakeAsync require sync execution flow, which lead us to critical differences as:

• runZonedGuarded sync execution
• different error/act/etc handling
• possible confusion / false positive results of usage same method for fakeAsync / normal execution - Prevent accidental misuse of fake_async when using async/await dart-lang/fake_async#38
• and most important fakeAsync issues, which prevent us to mix fakeAsync / normal execution in the same Zone:
  1. Why does making the callback function async break expect? dart-lang/fake_async#51
  2. Add some way to go into a "normal" execution mode, and then back into being controlled by fake async dart-lang/fake_async#24

[mugbug]

Not sure I get it, but my suggestion was to share internal code, not external. So we'd still have the current blocTest and testBlocFakeAsync methods, but the internal code of them will be somehow shared. In this case we won't have breaking changes since the public API for blocTest will remain the same. Not sure about the 2nd point but I suppose we can choose which code to share, so we should be good as well. Does it make sense?

[PankovSerge]

Got your point, @mugbug The duplicated code has been extracted to a private functions.

cc: @tenhobi

[mugbug]

LGTM! Now I suppose we just need to wait for an approval on the code solution and then work on some examples and documentation updates. Good job!

[mugbug]

I suppose we could also add some sort of example using fakeAsync.elapse which is kind of the main purpose of this new method, wdyt?

[mugbug]

We might wanna update the README.md docs as well and any other sort of documentation bloc_test might have

[tenhobi]

I really like this as it can make testing blocs faster. 👍

As mentioned, I would also like to see some unification of testBloc and fakeAsyncBlocTest to make it easy to maintain.

[tenhobi]

Look fine by me, just some formatting nits. All tests pass, seems good.

@felangel can you take a look at it? 🙌

[tenhobi]

Hey, @felangel, can you look at this? Seems kinda useful. Thanks!

[felangel]

Hey, @felangel, can you look at this? Seems kinda useful. Thanks!

Yup will look this weekend. Sorry for the delay!

[tenhobi]

Hey, @felangel, can you look at this? Seems kinda useful. Thanks!

Yup will look this weekend. Sorry for the delay!

So that didn't work out. :D

Since I got another random test fail due to time issues, I remembered this PR and just wanted to ping you. :)

[karvulf]

This PR would be really useful for us, thumbs up 👍

[test0terter0n]

Also would be happy to see this

[felangel]

I'm catching up on this (sorry for the delay) and am going to spend a bit of time to see if there's a way to unify these APIs in a non-breaking way rather than exposing two almost identical APIs.