Skip to main content

A month of Flutter: mocking Firebase Auth in tests



Originally published on bendyworks.com.

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 FirebaseUserMockGoogleSignInMockGoogleSignInAuthenticationMock, 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 =
      GoogleSignInAccountMock();
  final GoogleSignInAuthenticationMock googleSignInAuthenticationMock =
      GoogleSignInAuthenticationMock();
  final Auth auth = Auth(
    firebaseAuth: firebaseAuthMock,
    googleSignIn: googleSignInMock,
  );

  test('signInWithGoogle returns a user', () async {
    when(googleSignInMock.signIn()).thenAnswer((_) =>
        Future<GoogleSignInAccountMock>.value(googleSignInAccountMock));

    when(googleSignInAccountMock.authentication).thenAnswer((_) =>
        Future<GoogleSignInAuthenticationMock>.value(
            googleSignInAuthenticationMock));

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

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

    verify(googleSignInMock.signIn()).called(1);
    verify(googleSignInAccountMock.authentication).called(1);
    verify(firebaseAuthMock.signInWithGoogle(
      idToken: googleSignInAuthenticationMock.idToken,
      accessToken: googleSignInAuthenticationMock.accessToken,
    )).called(1);
  });
});
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 GoogleSignInmock, it should return an instance of the GoogleSignInAccount mock using thenAnswerthenAnswer 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),
  ));

  when(mock.signInWithGoogle())
      .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));

  verify(mock.signInWithGoogle()).called(1);
});
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

Comments

Popular posts from this blog

Sync is currently experiencing problems

Update : I now recommend you install Google Chrome  and  disable  the built in Browser as it supports encrypting all synced data. After picking up a gorgeous  Galaxy Nexus yesterday I was running into an issue where my browser data wasn't syncing to the phone. After a little Googling I found this is commonly caused by having all of my synced Chrome data encrypted instead of the default of only encrypting the passwords. These are the steps I went through to get my dat syncing again without losing any of it. The exact error I was getting was "Sync is currently experiencing problems. It will be back shortly." In Google Chrome open the personal stuff settings page by clicking this link or by opening the wrench menu, and click on "signed in with example@gmail.com".  Hit "disconnect your Google Account" to temporarily disable syncing from your browser. Visit the Google Dashboard and "Stop sync and delete data from Google". I waite

A month of Flutter: a look back

Originally published on bendyworks.com . This is it. 31 blog posts in 31 days. Writing  a month of flutter  has been a ton of work but also lots of fun and a good learning experience. I really appreciate how supportive and and positive everyone as been. Publishing experience For the series I've been posting on  bendyworks.com ,  DEV ,  my personal blog , and  Medium . After publishing to these sites, I would put the Bendyworks link on  Twitter ,  Reddit , and the  Flutter Study Group Slack . Posting to DEV was easy as they use Markdown just like the Bendworks blog. DEV also has built in support for a  series of posts  so it's easy to read the entire series. I did have to manually upload any embedded images. DEV also has a number of  liquid tags  for embedding things like GitHub issues that I didn't make as much use of as I should have. Blogger is rich text so it was easy to copy/paste the rendered posts. This would hotlink all the images though so I had to rem

A month of Flutter: the real hero animation

Originally published on bendyworks.com . For the last post before the month's wrap up tomorrow, I wanted to do something more fun: use a  hero animation between the home page list and the individual post page. When I first implemented the  Hero  animation it never worked going back from a  PostPage  to the  HomePage . The reason was that  HomePage  would get rerendered and that would  generate new fake posts . So I moved the fake data generation up a level to  MyApp  and pass it into  HomePage . This is more realistic as going to the  HomePage  shouldn't request the  Post s every time. HomePage ( title: 'Birb' , posts: _loadPosts ( context ), ) The  PostPage  implementation is a simple  StatelessWidget  that takes  Post  and renders a  PostItem . This will become more complex as things like comments and likes are implemented but works for now. class PostPage extends StatelessWidget { const PostPage ({ Key key , @required this