As promised, this week's edition is an Android-flavored follow-up to last week's tip on seeding the iOS simulator with test photos. The problem we're trying to solve is how to get pictures with known content onto the device for use in our App Under Test. This is a requirement for any type of app that utilizes or processes images.
How do you test that your app does the right thing to a user-provided image?
- Take some image you have lying around, and input it manually to your application.
- Manually run the app function on your image. Maybe this is applying a certain type of filter, for example.
- Still manually, extract the modified image from your app any way you can (texting it to yourself, for example!)
What these steps do is provide a gold-standard before-and-after which you can use as a test fixture. In an automated fashion now, we can provide the app with the same initial picture, run the desired function, and then retrieve the modified image. We can verify this modified image is byte-for-byte equivalent to our gold standard to ensure the app functionality still works as expected.
Test your Android apps on real remote devices seamlessly. Learn more.
In this edition we focus on the problem of getting our initial picture onto the device. How does one do this for Android? Happily, we use the same function as for iOS: pushFile. Under the hood, pushFile uses a series of ADB commands to shuffle the image to the device and then broadcast a system intent to refresh the media library. Since different device manufacturers put pictures in different places, you do need to know the path on your device that stores media. For emulators and at least some real devices, the path on the device is /mnt/sdcard/Pictures, so this is an important constant to your remember. As an example:
As you can see, the first argument is the remote path on the device where we want the picture to end up. This is where you may need to refer to documentation on your particular device or Android OS flavor to ensure you have the right path. The second argument is the path to the file on your local machine, where your test is running. When the test executes, the Appium client will encode this file as a string and send it over to the Appium server, which will then do the job of getting it on the device. This architecture is nice because it means that pushFile works whether you're running locally, or on a cloud provider.
Let's take a look at a complete working example. In this example, we automate the built-in Google Photos app. First of all, we set up our desired capabilities to just use a built-in app:
Once the app is open, we have to navigate through some UI boilerplate and other things Google wants us to do to use their cloud. Of course we are robots and not interested in their cloud! I've put this app state setup into its own method, along with setting up some locator constants, and logic that removes any existing pictures to make our verification easier later on:
Finally we can get to the meat of our test, which relies upon the appropriate device media path constant:
As you can see, the actual bit we care about is as simple as calling pushFile. For the sake of this test, we are simply verifying that our picture exists at the end. In a real-world scenario, we'd then run our app functionality on the picture, and retrieve it from the device to perform some local verification on it.
Bringing it all together, the entire test class looks like the following:
As always, you can check out the code in the context of all its dependencies on GitHub!