A full tutorial on FusionAuth Android SDK Test.
Using OAuth2 with a browser popup for Authentication can be tricky to use during automated testing in an Android Emulator. We made some efforts in the development of the FusionAuth Android SDK and made the test available in this Quickstart as well.
In this doc, we go in to detail on how to create the test with a real FusionAuth backend and what to look for in an automated testing environment.
We intend to test all use cases relevant for this SDK, which include: Login
Refresh Token
User Info
Logout
in combination with certain Test Data.
At first glance, these may seem like trivial tests, but we are seeking specific results for each use case and use them repeatedly in automated testing.
- Does it redirect to FusionAuth?
- Does a successful login result in a redirect to the Home screen?
- Is it refreshing the Token?
- Is the User Info received?
- Depending on the different User Info returned, are all the different data sets handled properly?
- Does it redirect to FusionAuth?
- Does it invalidate the user session?
- Does it return to the Login screen?
All the relevant data for testing is defined in FusionAuth which includes multiple flavors of Applicatoins and Users.
To be able to test the different scenarios FusionAuth will be initially configured with these settings:
- An update to the Tenant Theme including the ChangeBank Theme to make the look and feel of the login the same as the ChangeBank App.
- The Tenant Issuer will be set to
http://10.0.2.2:9011
to allow for testing with Android Emulator. - Two Applications
Example Android App
andSecondary Application
to test users with and without access to the Android App. - Your client secret is:
super-secret-secret-that-should-be-regenerated-for-production
- You will have three example usernames available with slightly different user profiles
richard@example.com
,monica@example.com
andgilfoyle@example.com
. All having access toExample Android App
where the password for all three ispassword
. - And an example user without access
erlich@example.com
to theExample Android App
- Your FusionAuth admin username is
admin@example.com
and your password ispassword
. - Your fusionAuthBaseUrl to access FusionAuth is
http://localhost:9011/
The Quickstart includes a Full End 2 End Test that uses all the different functionalities provided by the example App.
Starting the emulator requires the right image for the test, we’re using the google_apis
images for the last 5 API level.
In particular 29, 30, 31, 33, and 34, the 32 API level is skipped as it is a special Android 12L release for tablets and foldables with different layouts we're not concerned about.
Android Studio offers you to configure and handle emulators within the IDE, but you can go via the emulator commandline too.
If you’re automating your tests with a test matrix, it is important to know the change of the architecture starting at API Level 31 to x86_64
from previously x86
.
Which results in our case in the following five emulator configurations:
api-level | target | arch |
---|---|---|
29 | google_apis | x86 |
30 | google_apis | x86 |
31 | google_apis | x86_64 |
33 | google_apis | x86_64 |
34 | google_apis | x86_64 |
An example of such an automation you can find in the e2e-test workflows of the FusionAuth Android SDK.
Every time an emulator is started for the first time the Browser setup is not suitable for Testing as it will popup different modals like Welcome to Chrome
or Sign in to Chrome
, which are changing with every Chrome version.
To prevent chrome displaying any of these modals no matter the version, we execute the following commands once the emulator is started:
adb shell pm clear com.android.chrome
adb shell am set-debug-app --persistent com.android.chrome
adb shell 'echo "chrome --disable-fre --no-default-browser-check --no-first-run" > /data/local/tmp/chrome-command-line'
This is something you have to do only once for your emulator. But gets important during fully automated testing scenarios in a workflow, where the emulator is setup from scratch with every test.
With Android Studio you can start the emulator and start chrome manually to skip the modals, or use the adb
command (Android Debug Bridge) which can be found in your Android SDK installation:
$HOME/Android/Sdk/platform-tools/adb
All thought there are a lot of log details in your IDE and automated workflow to help to debug a failed test. It makes sense to watch the test in the emulator or to record the test as a video for further debugging input and context.
If you automate your test in a workflow you can pass this before starting the test command:
adb emu screenrecord start --time-limit 300 ./recording_video.webm
Depending on the build time of your App you might see only a Mobile screen for some time untill your App is started and displayed.
The setUp
test initialization includes the following steps:
- Initializes
Intents
. - Sets up
uiAutomation
to interact with the system UI.
This test validates the application by executing the following steps, as a user would:
- Taps the login button(
start_auth
). - Waits for the login form to appear.
- Fills in the username(
richard@example.com
) and password(password
) in the login form. - Submits the form using the enter key.
- Waits for the token view to be shown(
sign_out
). - Checks the refresh token functionality by comparing the token expiration time before and after the refresh.
- Taps the logout button(
sign_out
). - Waits for the login activity to be displayed again.
- Repeats steps 3-8 for a second user, using username
gilfoyle@example.com
and their password.
This test is then repeated a second time with RepeatRule
to ensure logout was successful and the login form is displayed again.
Helper methods are used throughout the test to interact with the UI:
closeKeyboardIfOpen
: Closes the system's keyboard if it's open, preventing it from obscuring the UI elements being interacted with.
The test concludes by releasing the initialized intents in the tearDown
method.
The constants used in the test include:
USERNAME
,PASSWORD
: Credentials of the first user.USERNAME2
,PASSWORD2
: Credentials of the second user.TIMEOUT_MILLIS
: The duration for which the test waits for the UI elements to appear in the system, expressed in milliseconds.
Please note that the username, password, and timeouts would typically be environment-specific and not part of the test code.