As your Flutter apps get more complex, testing becomes more important. Testing combined with continuous integration (CI) is a powerful combination for maintaining your app.

What is Continuous Integration?

Continuous Integration (CI) is the practice of automatically running your tests project-wide to provide visibility into how well your tests cover the functionality of your app. CI can also be used to automatically build your app, generate a project-wide code coverage report, and even auto-deploy to the Play and Apple stores, etc…

How to configure CI for Flutter

Here is how to set-up your Linux and MacOS environment on Travis for unit, widget, and integration testing. It includes how to run the Android emulator on Linux and the iOS simulator on MacOS (for integration testing). Also included is how to generate a project-wide code coverage report. BTW: Travis-CI and CodeCov are available for free for open source projects.

All the configuration information is contained in the .travis.yml:

Let’s see it!

Here is the default Flutter counter app running on Travis (click to see build):

The integration test is failing on Linux where it is running the android emulator. This is because cloud vendors do not support hardware acceleration or graphics which results in timeouts. The iPhone simulator does not timeout as easily.

The Issue

The solution is usually to add extended timeouts to the integration test. However the android integration test on travis is still timing out. I filed an issue with Flutter about this:

The temporary workaround is to build on MacOS running iOS simulator only.

The following is a more complex example of how the Flutter Sample Architecture github repo uses this method of CI configuration to run unit, widget and end-to-end integration tests on multiple apps in a single build. It so far has not run into this particular timeout issue:

The Issue Fix

The Flutter team has been very quick to respond to the above issue. A new feature has been added to the flutter driver (for integration tests) to allow for a global timeout multiplier for emulators running in the cloud. This resolves the issue.

Click to see build result

Let’s see it in action!

Here is the source code with links to the Travis build and Codecov coverage report:

Conclusion

Running tests automatically when the codebase changes makes for good quality code. This allows you to add progressively more advanced features with confidence as the code base increases in size.

In a follow-up article I will take this one step further and show how to auto-deploy a Flutter app to Apple and Play stores using Fastlane on Travis.

Finally…

Let me know if you have any questions or comments about this method of continuous integration for Flutter, below or on GitHub or Twitter.

If you think this article is useful, clap, like, subscribe and share with your friends for more Flutter developer articles.