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

CloudSense: the Future of Advertising

With the whole cloud taking off and more and more services switching to a push it into the cloud, leave it there until you need it, and pull it out model. I can only imagine what will be switching to this model soon. Oh wait. I can imagine.



Advertising!


Reading an article about how Avril Lavigne is supposed to have a $2 million check "appear" in her mailbox because of the absurd number of streams her videos get from YouTube got me thinking about creator compensation. The problem Avril is having is, a) Google wants to keep the money, and b) Google is having trouble figuring out how to monetize video streams. But on a grander scale it is whoever puts the ads on the page that gets the money not the content creator.

Little known @Twitter and @TwitterAPI tips and tricks

Be sure to comeback as new tips and tricks get added. If you know of anything I missed be sure to let me know.

Static URL for profile images based on screen_name:

https://api.twitter.com/1/users/profile_image/abraham

* This performs a http redirect to the actual profile image URL. Currently https redirects to http. You can also add "?size={mini | bigger | normal}" to get specific sizes.

Redirect to profile based on user_id:

https://twitter.com/account/redirect_by_id?id=9436992

In_reply_to_status_id mentions:

https://api.twitter.com/1/statuses/update.json?status=reply+to+@abraham&in_reply_to_status_id=12410413197

* In the web interface new mentions are only replies if they start with @screen_name. By pushing @screen_name further along in the string your followers who do not follow @screen_name will still see the status.

Profile image sizes:

http://a3.twimg.com/profile_images/54160223/chart-black-small.png

* By default you get the original image size you can add _mini, _normal, and …

Installing Storytlr the lifestreaming platform

"Storytlr is an open source lifestreaming and micro blogging platform. You can use it for a single user or it can act as a host for many people all from the same installation."

I've been looking for something like Storytlr for a few months now or at least trying to do it with Drupal. While I love Drupal and FeedAPI I did not want to spend all that time building a lifestream website. So I've been playing around with Storytlr instead and found it very easy. Here is how I got it up and running on a Ubuntu EC2 server. You can also check out the official Storytlr install instructions.

Assumptions:
LAMP stack installed and running.Domain setup for a directory.MySQL database and user ready to go.Lets get started!
Get the code: wget http://storytlr.googlecode.com/files/storytlr-0.9.2.tgz tar -xvzf storytlr-0.9.2.tgzYou can find out the latest stable release on Storytlr's downloads page.

Import the database:
Within protected/install is database.sql. Import this into your empt…