DEV Community: Nick Manning

Core Flutter Testing Concepts: mocking, repositories and integration testing. A brief overview.

Nick Manning — Tue, 01 Feb 2022 05:39:22 +0000

In this overview, I'll be covering integration testing concepts, using repositories and mocking in Flutter. Part 2 of this article will cover a detailed code walkthrough so stay tuned here and at https://youtube.com/c/seenickcode!

Integration testing ensures that your app can run properly on either a real device or a simulator and that the main components of your app seamless work together without any issue.

In addition to integration testing, we also have something called unit testing, where each individual atomic "unit" is tested. In the Flutter world, unit testing is also known as widget testing, where we ensure individual widgets work the way we want them to work.

This tutorial will cover the former, integration testing.

What we fundamentally prove with an integration test, at the very least, with even just a few lines of code, is if our app can startup and load properly. The benefit here is that if something goes wrong, say that there's a bug that is only exposed when we distribute the app and it's started by users, we catch it early on in the development lifecycle.

Another thing that we prove out in integration testing is, typically, can our individual screens load, can a user transition from screen to screen and are basic interactions, such as tapping buttons, entering text in a form, etc triggering the desired output?

For example, a typical integration test would start our app, load up the first screen for the user (again, on a real device or simulator), we interact with a few critical pieces of functionality and that the app behaves as we expect, especially without any hanging, crashing or without any undesired interactions.

So why does this title mention "repositories" and "mocking"? Well, these tie in typically with integration testing.

You see, it is not typically best practice to rely on external services when we run an integration test. An external service is typically a web service, for example. This is because that specific service has its own test. In other words, we know it "works". Second, calling out to external services slow down the integration testing process. Our tests can break if that service is down for maintenance or unavaialble. Our integration tests shouldn't rely on external services to simply run. We want our external service which our tests may rely on to be predictable.

That's why we typically will mock the external service with a bit of code. This gives us fine grained control of its behavior.

Now, how can we mock external services? Well, if we utilize a specific pattern called the "repository pattern", we can, depending on how our app is run (either via an integration test or via normal execution), our code can choose to mock or not mock.

The repository pattern's role is to simply abstract away the "how" of data access. Say we have a bit of code that calls out to a web service, we can wrap that logic in a method that allows the developer to swap out this logic "under the hood" if he or she chooses to do so.

We create a "repository" which can be a standalone class, containing methods that allow us to define a layer that other parts of our code can use, without being concerned about how we access the data.

For an example, we can create a "user repository", again, just a class, that has a single method, "get user". The "get user" implementation will contain all the nitty gritty business logic on how we call out to a web service, using HTTP, JSON, deserialization, etc.

Now, take our frontend, UI code in a random Flutter widget. If this widget needs to get a user, for example, the code for this is very simple, we just interact with an instance of a "user repository" and call our method. No messy code mucking up our widget.

What's cool about this pattern is that, it's like really anything else in software development, where a codebase offers abstractions upon abstractions upon abstractions. Kind of like an onion. We do this to make our code modular, easy to use (especially if we're working with other developers) and as easy as possible to refactor and change.

What's even more cool about this pattern is that, as it pertains to integration testing, we can "mock" our repositories by creating different variations of them, depending on what we need.

An example of a "mock" "user repository", from our example above, can have a "get user" method that simply returns a hardcoded user, instead of calling out to an external service.

Overall, mocking is an important concept in software testing, be it in frontend development, backend development or really anything you can think of.

Additionally, repositories allow us to greatly simplify our code. When it comes to sometimes, messy, boilerplate code to access data sources, such as a web service or a database, repositories provide a nice layer of abstraction, especially when working with a development team, large codebase or for our case mentioned above, integration tests.

For a continuation of this overview with a real coding walkthrough, check out my YouTube channel: https://youtube.com/c/seenickcode where I post a new full stack intermediate Flutter tutorial every other week.

Happy Fluttering,
Nick
https://twitter.com/seenickcode

Practical Flutter: 6 Tips for Newcomers

Nick Manning — Thu, 05 Jul 2018 15:49:31 +0000

This article is a re-post from my original post on Medium.

I've just submitted Steady Calendar, a minimalist habit tracker app, on the Google Play Store, design by my wife Irina and developed in short order by yours truly in the little free time I have being a new father. The app was a port from iOS to Flutter. After speaking about the experience (slides) at last week’s Flutter Camp, organized by @flutterfyi, I've decided to boil my talk down to something more meaty for everyone and make it a prelude to what an upcoming Flutter course, Practical Flutter, will be all about.

Well, after writing this app, with little free time yet without cutting really too many corners, I wasted a lot of time with distractions on what I thought I had to learn about Flutter, which in the end wasn't very useful and was sort of time lost.

So with that said, here’s some advice for newcomers to Flutter.

Keep it Simple When Getting Started with Widgets Flutter heavily uses Material Design widgets in examples and throughout most of its library. If you want to quickly get a UI together or have no time to write an app for Android and iOS, stick to Material Design.

Yet the problem with Material Design is it may alienate your iOS users unless customized properly. Google has been recently making efforts to make its library more flexible and show how adaptable it is, encouraging developers to break out of boring, repetitive UIs that all just look like Google Docs.

Flutter does offer “Cupertino” iOS style widgets yet this comes at the cost of needing to do some heavily code splitting, since these widgets require other parent widgets to work properly. Plus, Google isn’t heavily focused on offering a full blown comprehensive set of iOS widgets, after speaking with one of it’s employees at a recent event.

In my next app, I will be customizing Material Design heavily to match design needs yet here are some of the widget you may want to learn for now to stay flexible and get the most out of your time:

Scaffold and an AppBar (container for a screen and nav bar, respectively)
Layouts, with Column, Row
Container (ability to set ‘padding’, ‘decoration’, etc)
Text
AssetImage (NetworkImage as a bonus)
RaisedButton (forgot icons for now)

Forget Learning Dart From Day One Flutter uses Dart, a language that is very easy to pickup, even for folks new to software development. Yet getting an app running and rendering some simple UI does not at all require any Dart knowledge.

After you’re comfortable with learning the basics of layouts, getting some content on the screen, then take an entirely separate day to read up on Dart. After that, you’ll be ready to learn things like handling events (i.e. tapping a button) and maybe even fetching data from an API, depending on your experience level.

Stick to Stateless Widgets For Now

‘StatelessWidget’ is the default class any Widget will extend in Flutter. As the name implies they are for rendering widgets that will not need to hold any state.

In terms of it’s counterpart, ‘StatefullWidget’, Flutter’s documentation presents this by showing how to say, handle an event and change some information that’s on a screen. If you’re a newcomer to programming or even a junior developer, learning this in the beginning is by no means required. I say this because in the beginning of learning anything, motivation is the key to keep going and your primary focus should be getting comfortable with rendering a nice looking screen with some content.

Establish Some “Motivation Milestones”

Again, when learning anything, hitting some important milestones is key to staying motivated. Here are some of my recommended learning milestones:

Milestone One: Be able to develop a screen with a simple layout, text, a non-working button, and an image.
Milestone Two: Be able to run your app on your actual phone. This is very cool and really motivating.
Milestone Three: Learn how to hook up a button, change some state and render it on the screen by using a StatefulWidget.
Milestone Four: Take a few hours to read up on Dart (this step can even come before the previous milestone if you’d like).
Milestone Five: Be able to fetch some data from a public API (examples) and render it on the screen. Understand how to work with JSON and deserializing it.
Milestone Six: Release an actual iOS and/or Android build to a friend. This will surprise you but I really believe in doing this early, unless you’re still evaluating to see if Flutter is right for you. Showing an app you wrote, even if it’s not at all useful, to friends and family and sending it out to a test user via iTunesConnect or the Google Play Store (easier) and doing this early on is the really an amazing way to stay motivated and confident that you can crank out an app to the public one day.

Learn How to Get Help

Get used to going to the Flutter Google Group if you can’t find an answer to a problem on Stack Overflow. I recommend the former over Stack Overflow when asking questions actually. You can read more advice here.

Try to find a few mentors that can help you as well. You’ll find the Flutter community is wonderfully engaged and passionate.

Share Your Work

I’ve found that Twitter is a great way to share what you’ve done. Even if it’s something simple, simply posting a screenshot of your app and mentioning @flutterio is really motivating.

Final Thoughts on Learning
Overall, in terms of learning resources out there, there’s a lot available yet I’ve found that there isn’t enough real, end to end, battle tested tutorials on Flutter out there. Sure there’s your Google-produced YouTube videos and Udacity courses and these are great, yet a lot of the time they cover 1/5th of what you’ll need to learn to get a real app into the app store(s). I say this because after writing a port from iOS to Flutter for a simple app I wrote, Steady Calendar, recently, I found that things like working with JSON, APIs, manging multiple build environments, localization, caching, code organization, state management, tweaking Material Design for really custom UIs, etc took some digging.

So with that, I plan to release a beta Flutter course which will take my experiences learning Flutter and boil it down to practical, more “end to end” type tutorials which will focus on Flutter and all the other know-how it may take to write a real app.

If you’d like to sign up to get notified when I release the first lesson in July ’18, sign up here: Practical Flutter.

Happy Fluttering.