Photo by Minku Kang on Unsplash

Introduction

In the previous article, we defined a workflow to automate our test suite using Firebase and Codemagic.

On this article, we are going to review the native configuration required on the underlying Android project.

Next time, we will check the CI/CD pipeline configuration and the results after running the integration tests. So let’s get started!

Quick recap

Automation workflow

  1. Create Firebase Project
  2. Configure project by adding an account service
  3. Enable Cloud Tools Result
  4. Update underlying native Android project
  5. Configure underlying native Android Test Runner
  6. Set up Codemagic pipeline

As said before, we already reviewed the first 3 items, so let’s continue from item number 4.

4. Update native Android project

Configuration required in the “android” folder under our Flutter project is quite straightforward. Only 2 changes are required:

  • Bring up-to-date the Gradle version
  • Add the Google Services dependency

Updating Gradle

Gradle is the underlying build mechanism used in Android. When it comes down to building and running some Android app, Gradle does all the heavy-lifting for us.

Gradle is distributed in 2 formats:

  • the main build tool itself (aka “gradle”)
  • the helper script used when gradle is not available (aka “wrapper”)

Some errors may be thrown when using older versions of Gradle, so we have to update it by changing following items:

  • file “android/build.gradle” (external, at project level)
Main gradle configuration file
  • file “android/gradle/wrapper/gradle-wrapper.properties
Gradle helper script set-up file

On both files, only thing we have to do is set at least the version depicted on the screencaps.

Adding Google Services dependency

Since gradle is the native build mechanism for Android, it also takes cares of 3rd party libraries and dependencies used in our project.

To get our tests running automatically, we must include the following dependency in our native Android project:

classpath “com.google.gms:google-services:4.2.0”

After that, open a terminal, change from your current directory to the Android folder and then run:

./gradlew build

to force a rebuild.

5. Configure native Android Test Runner

Under the hood, our Flutter integration tests will be executed on the underlying testing platforms. So, in Android, our Flutter integration tests will become Android Instrumentation tests. On iOS, they would be XCUI tests, and they would required some configuration too.

2 changes are required here as well to get our tests up and running on Android:

  • configuring the gradle file
  • adding a main activity file for test

Gradle configuration

Android Instrumentation tests are run on a separate environment and use a special object, called Instrumentation, that grants access to the application context and allows the execution of actions over the app under test.

The default Android project shipped on a Flutter project does not contain the configuration for Android Instrumentation, so we have to modify:

file “android/app/build.gradle” (internal, at module level)

by setting manually the testInstrumentation property in the defaultConfig block:

Default config on build.gradle

and also adding the following libraries in the dependencies block:

Test dependencies on build.gradle

Adding a test Main Activity

The instrumentation tests will require a specific main entry point, as any other automatic task.

In order to provide it, first we create the following directory hierachy:

/android/app/src/androidTest

After that, we have to reply the package structure created in the “main” subset. On this project, that would be:

java.com.example.fooderlich

so, when adding them both, we end up with something like:

/android/app/src/androidTest/java/com/example/fooderlich

Finally, once we have created the folder structure, we have to add a main test activity file. The code contained on this file is common to any project, so it can be used as a template: the only thing we have to change is the project package, as shown in the following screencap:

Sample for main activity test file

Recap

As you can see, the underlying configuration for our test automation is quite simple! On the last article of this series, we’ll check the Codemagic setup so we complete the whole workflow.

Sample project

Check out the following repository containing the complete project:

https://github.com/begomez/Flutter-Test-Automation

Write you next time!

Join the Conversation

1 Comment

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: