Testmunk joined Snapchat. For testing services, check out TestObject.

Articles


How to test location-aware features on real devices

Posted by on June 22nd, 2015

If you have a close look at the apps on your homescreen or phone in general you will realize that many of them are location aware. This starts with facebook of showing you friends nearby or twitter showing you location-based ads. Snapchat lets you choose a location based filter. Uber and Lyft show you cars/drivers using the service around you. Yik Yak, designed to post anonymous banter on college campuses, have set up geofences around high schools to prevent their app becoming an inflammatory high school gossip board. Tinder shows ‘good’ matches around you. With the premium version you can even change your location to your next travel destination and get a new set of matches in advance. The list and creativity of location based use cases goes on and on.

home_screen

A typical Homescreen, 15 out of 27 apps use location features

It is interesting to note that location based app development is not new. In fact, already in 2008 Sam Altman was working on Loopt, an app that showed the proximity of your friends as one of the first apps in the app store (See WWDC presentation). It is the proliferation of this technology in recent years, and the numerous ways in which it is being implemented that has surprised many. In the US especially, locationally aware apps have almost become the de facto standard, alarming some privacy advocates.

Why is there an increasing trend?

3 key developments have happened over the past years:

1) Hardware / Network coverage improvements: Smartphones have consistently improved on their GPS sensors, CPU, RAM and battery life, making location based features far more energy efficient, and in the process, more feasible to use every day. In addition, the coverage of LTE and 4G has tremendously improved (at least here in the US).

2) Smarter software: Apple and Google both have continuously been improving their Core Location APIs. These improvements include not only better permission schemas but also features such as indoor positioning capabilities (for example iBeacons), giving more flexibility and new scope to developers.

3) Behaviour change: App users are increasingly expecting location aware data and instant feedback. Some people in Silicon Valley joke about the “on demand” generation. These user are asking themselves the following questions, and demanding apps that answer them: Why should I plan my groceries for the whole week – like my mom is still doing it – if instacart directly picks up my location and delivers me the groceries I want? Why should I perform complex google searches, if yelp and foursquare show me the best places to shop around me?

What does this mean for development and test teams?

While these trends are of great interest, and deserving of their own study, as a company focused on test automation, our interest in location based apps is from a primarily technological perspective. This means that from our perspective, the increasing trend towards location aware apps means a corresponding increase in the number of companies looking for an answer to the question:

“how can we effectively test our location features?”

We often find our clients are concerned that “the emulator/simulator does not effectively simulate these features”, or that “we have seen issues on these particular devices”. Some companies have even reported to me that they had to book flights to far away locations, just to be reaaaaally sure the feature worked as intended.

Testing location based features on an emulator or simulator, while relatively straightforward, is inherently limited, as it may not reflect the multitude of hardware configurations inherent on real devices. At the same time, it is a burden to test location when it comes to real devices. This difficulty does not even account for the issues involved in running multiple tests on multiple devices, in order to test if your map and GPS integration works properly across different models and OS versions.

In the following article, we will explain how you can run automated tests that will analyze locational services on a real device plugged into your machine. By providing this free, open-sourced solution, you will be able to perform simple location based testing on your own. We can then help you to run the same script on our Testmunk platform, allowing you to see the benefits of testing on a large set of android devices.

How to test location feature on real devices

Prepare your build

To set up an automated test for locational services, you will first need to enable location mocking within your app. To enable location mocking, simply perform the following steps:

  1. Add ACCESS_MOCK_LOCATION permission in your android manifest file.
  2. < uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
  3. Next, make your build debuggable.
  4. android:debuggable="true"
  5. Enable “Allow mock locations” in your device settings.
  6. Settings -> Developer options -> Allow mock locations
  7. Finally, make sure you have the correct API_KEY and that your maps are showing. If not, please check how to obtain the API key.
  8. < meta-data android:name="com.google.android.maps.v2.API_KEY"     
    android:value="AIzaSyC2XxFdNDQjEgXVFnGhLE_jORlfYFpD3I0" />

Mock Location

With the above changes, your app should now allow location mocking. To test this functionality, use the calabash-console and enter the following information:

set_gps_coordinates(latitude, longitude)

If successful, you should see the below results:

{
"bonusInformation" => [],
"message" => "",
"success" => true
}

From this point on, Android will tell your application that the device is at the location of your choosing. Here is an example from Logcat:

05-29 12:20:13.150  30885-31643/com.testmunk.localization I/System.out﹕ Mocking location to: (40.748817, -73.985428)

Writing a Test

Github provides the following steps for locational services testing in your calabash scripts. Review the steps as provided below, or at the source.

Then /^I am in "([^\"]*)"$/ do |location|
  set_gps_coordinates_from_location(location)
end

Then /^I am at "([^\"]*)"$/ do |location|
  set_gps_coordinates_from_location(location)
end

Then /^I go to "([^\"]*)"$/ do |location|
  set_gps_coordinates_from_location(location)
end

Then /^I am at ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$/ do |latitude, longitude|
  set_gps_coordinates(latitude, longitude)
end

Then /^I go to ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$/ do |latitude, longitude|
  set_gps_coordinates(latitude, longitude)
end

As you can see in the above example, there are two possible methods. First, set_gps_coordinates_from_location will translate the location (like “New York”) to gps coordinates. It requires the geocoder gem to work. The second method, set_gps_coordinates, will simply set the latitude and longitude.

Example

Having set up location mocking on our test devices, it’s time to put things to practical use. Let’s use that knowledge to write a simple scenario for the app, showing the user’s current city.

loc_ex_la_ny

Scenario

Feature: Location

  Scenario: As a user with a new location I should see city I'm in
    Given I set my location to 34.052235, -118.243683
    And I wait for 5 seconds
    Then I should see "You are in Los Angeles"

    When I set my location to 40.748817, -73.985428
    And I wait for 5 seconds
    Then I should see "You are in New York"

You can find both the app and the tests here. Clone the repository and use the debug.keystore for resigning the .apk locally. This keystore is assigned with the maps api key that is used in the app.

Execution

As mentioned at the beginning of the article, github’s open source location mocking allows you to test any device locally, from your desktop computer or laptop. This allows anyone to test location mocking, but would be a rather time consuming process to perform over and over again on a large number of devices.

Fortunately, Testmunk allows the test to be run on several devices at once, and the test can be repeated on each device for a different location with relative ease.

Regardless of whether testing locally or via Testmunk, first, clone the repository and open the root folder in your terminal:

  1. git clone https://github.com/testmunk/calabash-location-mocking.git
  2. cd calabash-location-mocking

Local Execution

If running the test locally, continue with the following steps.

calabash-android run app-debug.apk features/location.feature
code_ny_la

If you need to create a new test server please setup the keystore first:

  1. First, copy ‘debug.keystore’ to ‘~/.android/.debug.keystore’ in order to use the keystore assigned with the maps api key defined in the AndroidManifest.xml file.
  2. Next, resign the .apk with the following command:
    calabash-android resign app-debug.apk
  3. Finally, run the tests again:
    calabash-android run app-debug.apk features/location.feature

Cloud Execution on Multiple Devices

With Testmunk, you can execute the tests in parallel on a large set of devices.

Simply by changing the location presented in each test step, and initiating the test again, you can duplicate the test as many times as you want, ensuring that your locationally aware app functions across a multitude of devices and OS versions.

The below image provides an illustration of our dashboard view. However, you can check the full results for yourself by clicking here. We hope you like it :)

dashboard_loc_ex_la

Summary

Testing locational services on different devices is fairly simple, using the above open source steps, but it can be time consuming to do on a per device basis. It is an important test to perform, however, as location based data is used in more and more apps, and is being integrated into the app in new and creative ways. Testing using a simulator simply does not provide adequate peace of mind that the app will function as designed, across the large array of potential android devices and OS versions.

Testing locational services on a per device basis, whether scripted or automated, can be time consuming. By providing cloud access to a large pool of devices, as well as allowing for quick, automated test deployment, you can cut the time for testing tenfold. This is true not only for locational testing but any number of scenarios. In addition, by supplying a large pool of cloud connected devices, we can expand a small development startup’s pool of available test devices considerably, allowing startups to compete with larger organizations on the testing front.

Regardless of whether your organization tests locally, or with Testmunk, we hope the how-to guide provided above will help you ensure your application’s locational services function as intended.

Are you using locational services in a new and exciting way? Let us know!

Talk to us and schedule a demo.

About the author:
Lukas is a QA Engineer at Testmunk helping some of the biggest iOS and Android apps to establish large scale automated test suites. Before discovering his passion for automation, he worked several years as a mobile app developer. He is passionate about agile and lean methodologies and in his free time he loves to ride his motorbike.

Testmunk automates mobile app testing

LEARN MORE

1 Comments Leave a Comment

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>