Firebase.initializeApp is not mocked about fake_cloud_firestore

[atn832]

Basically, FakeFirebaseFirestore() acts like FirebaseFirestore.instance. It implements the same API. So in your code, instead of using directly FirebaseFirestore.instance, you should actually use an instance of FirebaseFirestore, be it the real one (FirebaseFirestore.instance) or the fake one (FakeFirebaseFirestore()).

The error message you are getting, which states that you did not call Firebase.initializeApp, shows that you are still running the real Firebase code (probably FirebaseFirestore.instance) somewhere in your test.

You can refer to https://firebase.flutter.dev/docs/testing/testing/, in which I give the full code to testing a simple app. You can see that only main() calls Firebase.initializeApp, and passes a real FirebaseFirestore instance to the Widget. The Widget is then initialized with an instance of FirebaseFirestore. On the opposite, during the tests, we pass aFakeFirebaseFirestore instead of the real implementation to the Widget.

Let me know if you still have issues!

[AdrienLemaire]

@atn832 thank you for taking the time to reply during the weekend.
I see. If the firestore instance is a widget parameter, we can easily replace the real instance with a fake one when calling the widget.

Are best practices discussed somewhere ?
I'm new to flutter, and I suppose you don't define a firestore parameter on every screen widget, passing firestore around with each go_router route.

If I lift the firestore state up to the top App widget with provider, then use Consumer to retrieve the firestore data in my components, I would need to wrap all related test components in a FakeApp widget.
Would that be a clean solution ?

Something like:

Widget createHomeScreen() => ChangeNotifierProvider(
      create: (context) => FakeFirebaseFirestore(),
      child: MaterialApp(home: HomeScreen());
    );

void main() {
  group('Home Screen Tests', () {
    testWidgets('Testing content', (tester) async {
      await tester.pumpWidget(createHomeScreen());
    });
  });
}

Looking around, I found 2 interesting articles:

• Testable Flutter and Cloud Firestore with a FirebaseWaiter widget.
• Starter Architecture for Flutter & Firebase Apps using Riverpod which overrides the firebaseAuthProvider with a mockFirebaseAuth (not using fake_cloud_firestore).

[atn832]

Yes the sample code you propose is similar to what I use in my projects. I use InheritedWidget simply because it works well enough for my needs and doesn't add another dependency to the project. But the Provider API looks nice too!

Also I did not implement a FirebaseWaiter component because my app waits for several Future's. So it was easier to inline the FutureBuilder like this:

WidgetsFlutterBinding.ensureInitialized();
runApp(
  FutureBuilder(
    future: Future.wait([
      SharedPreferences.getInstance(),
      Firebase.initializeApp(
          options: DefaultFirebaseOptions.currentPlatform)
    ]),
    builder: (context, snapshot) {
      if (!snapshot.hasData) {
        return [waiting state widget];
      }
      final sharedPreferences = snapshot.data.first as SharedPreferences;
      return MyApp(sharedPreferences);
    },
  ),
);

Finally, the first article's approach works, but it is quite complicated: they introduce an interface abstraction, implement the fake CounterManager and in the end manage to test only the Widget. It does not test the FirestoreCounterManager nor the fake CounterManager. If they wanted to be thorough, it would require even more work.

I haven't read the second article, but thanks for sharing! I'll read it later.

I haven't checked the official Flutter docs in a while, so I don't know if those practices are documented anywhere.

[AdrienLemaire]

Thanks!
I now understand that the implementation differs depending on the code architecture and design patterns chosen.
It would be nice to have some examples for popular state management systems to get new flutter developers up to speed faster, but it's probably a bit out of scope for this library :)