When you are a QA set out to test an app made in Flutter, you’ll quickly realize there aren’t many sources of information available. Googling will get you scarce tips and tricks or well-established testing methods.

Working in Quality Assurance at a company with a very active Flutter team, I’ve done my share of testing and gained some valuable insights.

Let’s start with the basics. Flutter is an open-source user interface software development kit created by Google. It is used to build cross-platform solutions for Android, iOS, Linux, macOS, Windows, and the web from a single codebase. Flutter’s programming language is Dart, and the apps often make use of its more advanced features.

Flutter is commonly used for mobile app development. Both Android and iOS apps can share the same codebase, eliminating the need for separate native development. Couldn’t we do the same with React Native, you’re asking? Yes, but RN uses device-specific interface components, and many of them are platform-specific, which results in a significantly larger codebase than needed.

If you compare stars on GitHub, Flutter has a larger community than React Native, a case in point.

The very foundation of Flutter is that almost everything in the program is a widget. There are no distinct controllers, views, or layouts like in other frameworks. The widget is a unifying building block that covers almost every aspect of Flutter development. It can be anything from a single button to a full pop-up panel.

Flutter widgets are created with a modern framework based on React. They make up the entire UI and indicate how their present configuration and status should appear in the display. 

The composition method is superior to inheritance. The composition-based technique is used when widgets are made up of smaller widgets. You can use the Flutter API to mix numerous widgets to get the exact behavior you want.

The widget tree concept is essentially a ranked widget implementation that represents user interface components. These widgets can be stateless or stateful, and the distinction is determined by the state of the widget. It’s a handy tool for managing app states.

When it comes to web and desktop apps, compiling the Flutter source code into a native Windows, macOS, or Linux desktop program is possible with desktop support. Flutter’s desktop support extends to plugins as well, allowing you to install existing plugins for Windows, macOS, and Linux. However, to be considered fully compatible, a Flutter app mustn’t include any platform-specific implementations. 

Flutter provides a more customized UI than native platforms. However, it’s also slower, which means that screen jerks and terrible animations are possible. If the app needs to communicate with the device frequently, it’s probably not an ideal fit for Flutter. Flutter is best used for producing apps with a visually pleasing interface.

I’ve had experience with several Flutter apps, most of them fit in the same category, and the expectations were similar. Not much communication with the device was required, the app needed to be very UI-friendly and the overall testing experience was very pleasant.

However, once I tested a Flutter app that communicated with the device and biometrics a lot, and that one was a challenge to test because of some of Flutter’s limitations. You should keep this in mind when creating a testing plan for a Flutter app, it often depends on the app’s category. 

Flutter is focused on assisting developers in making their apps more accessible. It contains first-class framework support for accessibility on top of what the underlying operating system provides. This includes things like fonts in bold, readers for screens, and adequate contrast. I would also advocate for automated accessibility scanners in addition to testing for these specific topics.

Widget book is an open-source tool for creating Flutter UI widgets and pages. It can be very useful for QA because developers can implement it within the app. We can see every widget in the app, interact with it separately, and see any of the possible widget states. With the widget book, you do not have to verify everything in the design file, because the developer gave you a “shortcut”.

While testing Flutter apps I noticed some bugs appeared more often than others. Maybe we could have talked about Flutter-specific problems some time ago, but today it’s hard to pinpoint the exact issues that come in the package. What we can do is point out the places where Flutter is most likely to break so you can pay more attention to them while testing.

These places are all related to the app’s communication with the device. Keep an eye out for the following: 

The bug that personally bugged me the most was when the app often got stuck on the splash screen, which prevented me from testing it at all. It sometimes helped to reinstall the app or check the app’s permissions. I would definitely advise testing the UI on devices with punch hole displays because widgets can have some issues there, e.g. look broken, have a broken layout, or not be displayed at all.

Further, my impression is that Android does have a slightly higher number of issues with Flutter apps, which is one of the reasons you should test the app on both platforms. When it comes to mobile OS, Flutter apps are supported on Android API 19 & above and iOS 9 & above.

Automating the testing process on Flutter apps is possible, just like with any other mobile app. 

Testing Flutter apps, you basically learn from experience since there are hardly any resources available at the moment. What I’ve personally learned is that at the core, it isn’t that different from testing native apps. Some bugs do tend to pop up more than others, and I tried to shed some light on these. 

Hopefully, sources of information tackling QA issues, in particular, will follow the trend.