A month of Flutter: mocking Firebase Auth in tests

Sign in with Google adds a wildcard to the app: external services. External services are usually avoided in test environments because they create variance and complexity so today I'm going to talk about creating mocks to simulate interacting with these third-party APIs.

Mocks in tests provide two main features: stubbing methods and objects so they behave like real things and validation that methods and properties are called as expected.

To create a mock for FirebaseAuth is as simple as:

class FirebaseAuthMock extends Mock implements FirebaseAuth {}

I've also created FirebaseUserMock, GoogleSignInMock, GoogleSignInAuthenticationMock, and GoogleSignInAccountMock. For now they are mostly simple mocks but they can be created with more complex states and responses stubbed.

The majority of the tests written for yesterday was testing the Auth service.

group('Auth', () {
  final FirebaseAuthMock firebaseAuthMock = FirebaseAuthMock();
  final GoogleSignInMock googleSignInMock = GoogleSignInMock();
  final FirebaseUserMock firebaseUserMock = FirebaseUserMock();
  final GoogleSignInAccountMock googleSignInAccountMock =
  final GoogleSignInAuthenticationMock googleSignInAuthenticationMock =
  final Auth auth = Auth(
    firebaseAuth: firebaseAuthMock,
    googleSignIn: googleSignInMock,

  test('signInWithGoogle returns a user', () async {
    when(googleSignInMock.signIn()).thenAnswer((_) =>

    when(googleSignInAccountMock.authentication).thenAnswer((_) =>

      idToken: googleSignInAuthenticationMock.idToken,
      accessToken: googleSignInAuthenticationMock.accessToken,
    )).thenAnswer((_) => Future<FirebaseUserMock>.value(firebaseUserMock));

    expect(await auth.signInWithGoogle(), firebaseUserMock);

      idToken: googleSignInAuthenticationMock.idToken,
      accessToken: googleSignInAuthenticationMock.accessToken,

First I'm instantiating five mock objects and an instance of Auth which is getting passed the FirebaseAuth and GoogleSignIn mocks. These are the primary mocks that represent those two services in the functional code.

Within the test example I'm specifying that when signIn gets called on the GoogleSignIn mock, it should return an instance of the GoogleSignInAccount mock using thenAnswer. thenAnswer is just like thenReturn but is for returning asynchronous values.

There are then stubs for two more external services before the actual signInWithGoogle method being tested. This expect asserts the response is the mocked FirebaseUser that it should be.

After that I have three verify assertions. These check with the mocks to make sure the API methods were called with the expected inputs. With this test in place I can be reasonably sure that as long as the external services don't change their APIs, my code will keep working as desired.

The Auth tests need to be fleshed out some to make sure they handle error cases in the external services. There was an issue created to track adding this error handling.

The last part I want to test is that when a user taps on the Sign in with Google FAB, the Auth service will be called as expected. The pattern of mocks here is the same as above but just simpler.

testWidgets('Renders sign in', (WidgetTester tester) async {
  final AuthMock mock = AuthMock();
  // Build our app and trigger a frame.
  await tester.pumpWidget(MaterialApp(
    home: SignInFab(auth: mock),

      .thenAnswer((_) => Future<FirebaseUserMock>.value(FirebaseUserMock()));

  expect(find.byType(Image), findsOneWidget);
  expect(find.byType(FloatingActionButton), findsOneWidget);
  expect(find.text('Sign in with Google'), findsOneWidget);

  await tester.tap(find.byType(FloatingActionButton));


Testing is a critical aspect of making sure applications continue to work as they are changed. These are unit tests and widget tests which are important but there is a third type of test: integration. Integration tests are really good for making sure a full feature flow continues to work. I'll be working on adding integration tests in the future.

Code changes

Posts in this series

  • A month of Flutter
  • A month of Flutter: create the app
  • A month of Flutter: configuring continuous integration
  • A month of Flutter: continuous linting
  • A month of Flutter: upgrading to 1.0
  • A month of Flutter: initial theme
  • A month of Flutter: no content widget
  • A month of Flutter: a list of posts
  • A month of Flutter: extract post item widget
  • A month of Flutter: post model and mock data
  • A month of Flutter: rendering a ListView with StreamBuilder
  • A month of Flutter: Stream transforms and failing tests
  • A month of Flutter: real faker data
  • A month of Flutter: rendering network images
  • A month of Flutter: FABulous authentication
  • A month of Flutter: configure Firebase Auth for Sign in with Google on Android
  • A month of Flutter: configure Firebase Auth for Sign in with Google on iOS
  • A month of Flutter: Sign in with Google
  • A month of Flutter: mocking Firebase Auth in tests
  • A month of Flutter: delicious welcome snackbar
  • A month of Flutter: navigate to user registration
  • A month of Flutter: user registration form
  • A month of Flutter: testing forms
  • A month of Flutter: setting up Firebase Firestore
  • A month of Flutter: awesome adaptive icons
  • A month of Flutter: set up Firestore rules tests
  • A month of Flutter: Firestore create user rules and tests
  • A month of Flutter: WIP save users to Firestore
  • A month of Flutter: user registration refactor with reactive scoped model
  • A month of Flutter: the real hero animation
  • A month of Flutter: a look back