Skip to content

An extensible base project for implementing shared scenarios between an iOS and Android app.

Notifications You must be signed in to change notification settings

rooZzz/multiplatform-calabash

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Multiplatform Calabash

http://testingsyndicate.com

Impetus

Frequently, companies develop native mobile applications for both iOS and Android alongside one another. Usually, parity of behaviour between apps is an important requirement. If I switch platforms I don't want to find that several features I relied on are no where to be seen!

The apps will not be identical however - there may be differing design principles between platforms. For example, say I want to see my saved locations within the app. This may mean opening a burger menu on Android and tapping the Locations option, whereas there is a tab bar icon for the same purpose on iOS.

This project provides a framework for sharing as much test code between platforms as possible, allowing you to delegate behaviour only when you need to.

Structure

The multiplatform Calabash project structure

Explanation

Controller logic (i.e., navigation between screens, initiating the checks for elements, clicking buttons, etc) is defined in the base controller and inherited by all platform-specific controllers. Platform-specific controllers are optional, and should only be implemented if you need different functionality between platforms.

Screen queries (i.e. searching for the word 'Login' by text, or searching for an input field using id 'passcode_input') live inside the Screen files. Again, text between platforms should be pretty congruent, but you can optionally delegate to platform-specific screen files in the case of different queries.

Because the implementation details of the Calabash framework is hidden away in the helpers, you can quite easily swap out Calabash for a different framework without affecting the scenarios, steps, controllers or screens. Make sure you put anything Calabash (or other framework) specific methods inside these helpers to maximise ease of transition to another or upgraded framework in the future.

For the gritty mixin and redefinition details, have a look inside env.rb

Usage

Explore the Calabash folder. Hopefully the example controllers and screens are friendly enough for you to get the gist!

Basic rules:

  • Platform-specific controller class names must end with 'Android' or 'iOS'. Likewise for screen class names.
  • If you want a scenario only to run on the Android platform, tag it @android-only. Likewise for iOS, tag the scenario @ios-only.
  • If you want to add more controller or query functionality, do so in the respective helpers. Keep automation framework specific code out of the controllers/screens!

Android

Open the Android folder in Android Studio and build it - or navigate to the folder in your terminal and run:

	gradle assembleDebug

Navigate to the Calabash folder in your terminal and run:

	bundle install
	bundle exec calabash-android run ~/path/to/generated/apk --profile android

iOS

Open the iOS folder in Xcode and build the Calabash target.

Navigate to the Calabash folder in your terminal and run:

	bundle install
	bundle exec cucumber --profile ios

Logging

The LOG_LEVEL environment variable is used to control logging output. If you do not pass it, the default is logging to the file 'out.log' with log level 'debug'.

Run with LOG_LEVEL=0 for debug output, LOG_LEVEL=1 for info output, etc. For future logging, use:

	LOG.debug('This is some debug logging!')
	LOG.info('This is some info logging!')
	# etc

About

An extensible base project for implementing shared scenarios between an iOS and Android app.

Resources

Stars

Watchers

Forks

Packages

No packages published