This Bazaarvoice blog entry is co-authored by Tanvir Pathan as part of a Bazaarvoice internship project on the Bazaarvoice Mobile Team.
Automated testing of native mobile applications has long been a pain point in the world of mobile app development. If you are creating and distributing apps or open source SDKs across two or more major platforms (Android and iOS in our case), you can easily find yourself duplicating efforts to test the same source and business logic across different technology stacks. For example, if you have experienced developers and testers using Xcode for iOS apps, they may tend to automate testing with Instruments Automation, where Android developers and testers may automate with Espresso or UIAutomator. This becomes an expensive proposition for development and maintenance of unit tests, which can be costly as your test coverage increases.
Test strategy can also vary depending on the type of mobile app development your shop pursues: native, hybrid, cross-compile, mobile web. Hence, the selection of test tools will vary depending on how you build and deploy apps.
In this blog post, we’ll detail a novel solution to cross-platform testing of our native SDKs, along with some background of other mobile tool offerings. Our solution focuses on cross-platform open source mobile SDK testing utilizing Cordova to wrap our SDKs in a generic JavaScript interface, and Calabash to drive our cross-platform behavioral tests.
If you want to check out the full solution, the Cordova plugin and description on how to execute Calabash can be found in our Github repository.
How to View Mobile Application Development
Non-mobile app developers typically don’t actually know the difference between a web app, native, or hybrid app. If you work in any business that supports some kind of mobile solution (and you probably wouldn’t be reading this if you didn’t) it’s really important to understand some fundamental differences. It’s very easy to just throw out the word “mobile” in conversation and not realize there’s multiple parts to this elephant!
The table below presents four general categories of mobile application development. Keep these categories in mind when talking about “mobile” in general and don’t fall in the trap of the blind men and the elephant.
Mobile Development Types & Tools
Type
|
Description
|
Tools
|
---|---|---|
Native Application Development | Developers creating purely native apps will write in the language supported by their target platform. | For iOS apps, developers can write in Swift and/or Objective-C, while Android developers can write in Java (and C/C++ for lower level execution) |
Cross-compilation | Developers can also write apps for multiple platforms in a single language, such as Java Script. Cross-compilation tools will take a common language and actually convert it to the target language of the native platform. In this case, while developers aren’t writing in the native language, the tools create real native apps. | Some of the most common tools are: Appcelerator (JavaScript), Xamarin (C#), React Native (Java Script) |
Hybrid Applications | Hybrid apps utilize Web Views to display content, typically written with common web development technologies such as Java Script, HTML, and CSS. Hybrid apps will typically have a “bridge” that allows javascript code to communicate with the native libraries to do things like access the camera, location services, or contacts. | Cordova (aka PhoneGap) as the application container. Developers choose their favorite UI layer to work with Corodva: ionic, Sencha Touch, jQuery Mobile, Onsen, Framework 7. |
Web Applications / Mobile Web | A web application isn’t as much an application as it is a mobile optimized web site. Hence, you won’t find a Web Application in the App or Google Play Store, you just fire up your favorite mobile web browser and load the site. |
Cross Platform Mobile UI Testing Tools
When developing for native mobile, developers will typically write unit tests to check individual pieces of functionality and business logic, perhaps even employ certain mocking techniques to test networking and user interface capabilities without the need for a full application. However, when it comes to full system testing of full applications and SDKs, making the right selection can be a tough process. However, if cross-platform testing is your objective and you want to write all your tests in one common scripting language, the options narrow quickly.
While there are platform-specific UI automation frameworks for Android (Robotium, UiAutomation) and iOS (Instruments Automation, Keep It Functional, EarlGrey), there currently only two (that we are aware of) that allow us to test cross-platform with a common script.
Tool
|
Summary
|
|
---|---|---|
Appium | Appium lets developers write tests for applications without having to add any additional code the applications. It works with native, hybrid, and mobile web applications. | |
Calabash | Calabash is owned and maintained by Xamarin, and provides cross-platform testing for native or hybrid apps. Unit tests can be written in Ruby with Cucumber. |
2 Birds, One Stone
Making the decision to use Cordova and Calabash was fairly easy. First we already distribute our BBVSD via frameworks and libraries for iOS and Android. Second we know some of our customers are creating hybrid applications with Corodva. So we immediately thought: what if we could create a test environment that not only tests our SDK deliverables, but also provides our clients with an easy avenue to integrate Bazaarvoice services into their own Cordova app. Win! Win! As well, because we already use Cucumber extensively at Bazaarvoice, we decided to leverage our already strong in-house expertise and utilize an automation framework that is internally familiar.
Calabash Unit Tests
Another great thing about using Calabash at Bazaarvoice is that we already have an internal framework developed on top of Cucumber. Because Calabash layers on top of Cucumber, the paradigm and philosophy of writing human readable test cases still applies. The test cases utilize Behavior Driven Development modeling tools to add meaning to your mobile app testing.
Let’s say you are creating the same app for multiple platforms. Typically, you would have to write completely different sets of code to run similar tests. With Calabash, this is not the case. You write one set of code tests and make slight adjustments depending on the platforms in question and you are done! Best of all, in addition to Calabash being free, the test cases are super easy to write as a developer and even easier to read for others who may be interested in checking out the health of the project.
Needless to say, Calabash provides a lot of benefits for cross platform testing. Lets take a look at an example test case from the BVSDK Cordova Plugin project. Let’s go through a simple scenario based on the following app screens shots from the iOS simulator.
Say you wanted to count the number of products that were recommended by our Product Recommendations API. If you were doing it manually you would go through the following steps:
- Wait for the app to launch
- Make sure you receive a success alert and press ok
- Click the Recommendations tab
- Then count how many products there are and compare them to what you were expecting
Now how would we code this? Calabash has two essential components: one feature file and one ruby file. The feature file is where you write out the tests and the ruby file is used primarily to make custom functions if needed (although most of what you need comes right out of the box). So returning to our problem, writing out the test case, you simply write down those exact steps in the feature file:
Feature: BVSDK Demo App @recommendations_test Scenario: As a user, I want to get new recommendations Given the app has launched Then I should see "BVSDK has been built successfully." Then I press the OK button Then I press Recommendations tab Then I check number of products |
That’s really all there is to it. Of course, tests can be also written to be more platform specific when needed.
Entering the Matrix – Travis CI
We use Travis CI for all our public repos at Bazaarvoice. It’s awesome. But, we have to support multiple build tools on different virtual machines. Configuring all these build machines with custom tools sounds and build scripts really scary! Freak out!
The really slick thing about Travis CI is that you can test multiple configuration, variations, permutations, salutations, etc, etc, etc, by building a matrix in Travis’ Config file (.travis.yml). For our testing, since XCode only runs on OS X and it’s the only way to build for iOS, we must have an OS X image. For the Android Studio and Gradle build tools, we build against Linux. In addition there’s some common tooling we can install for each build machine. The result is that we can use two different VMs for testing each platform, with just one set of tests. Note in the test result below, the build jobs are defined by the environment variables defined in the Travis config file.
The .travis.yml script looks like this, where we build a matrix with environment variables and platforms:
matrix: include: - language: android env: TO_TEST = ANDROID jdk: oraclejdk8 - os: osx osx_image: xcode8 env: TO_TEST = IOS fast_finish: true android: components: - platform-tools - tools - android- 23 - build-tools- 23 . 0 . 3 - extra-android-m2repository - extra-google-m2repository - sys-img-armeabi-v7a-android- 19 install: - rvm install 2 . 2 . 0 - if [ "$TO_TEST" = "ANDROID" ]; then gem install calabash-android; fi - if [ "$TO_TEST" = "IOS" ]; then gem install calabash-cucumber; fi before_script: - if [ "$TO_TEST" = "ANDROID" ]; then chmod 755 createEmulator.sh; fi - if [ "$TO_TEST" = "ANDROID" ]; then ./createEmulator.sh; fi script: - if [ "$TO_TEST" = "ANDROID" ]; then chmod 755 androidTest.sh; fi - if [ "$TO_TEST" = "ANDROID" ]; then ./androidTest.sh; fi - if [ "$TO_TEST" = "IOS" ]; then chmod 755 iosTest.sh; fi - if [ "$TO_TEST" = "IOS" ]; then ./iosTest.sh; fi |
BVSDK Cordova Plugin Features
So what if I want to try out the BVSDK Cordova plugin? If you want more info or checkout the source code for the plugin and unit tests, just head over to our Cordova Github repo. There’s plenty of info in the README for running the examples and unit tests.
Open Source Contributions
If you are building a Cordova-based application and want to see other things added just let us know, or better yet submit a pull request and we’ll be happy to review it!