Transcript Calabash Structure

Calabash Structure
Andrew Reed
File Structure
•
•
Config/
o
cucumber.yml
Features/
o
o
o
o
o
o
android/
ios/
playback/
step_definitions/
support/
*.feature files
Config
In the config directory we have a single configuration file(cucumber.yml)
The file contains the configuration/commands needed to run the tests for
all platforms(android, ios).
So when we run the command to execute the tests:
Then we can specify what format/profile to use, it may become apparent
to run different methods for iPad and iPhone, or even OS versions. We can
do this by adding the cucumber.yml file and adding a new profile with the
required params.
Features
This directory contains all the features,tests
and how they run.
More importantly this folder contains the
.feature files which contains the BBD
Gherkin formatted instructions.
.Feature Files
All feature files must have a “Feature:” title,
then an optional “Background:” and a
mandatory “Scenario:”
•
•
•
Feature: Should be the feature name(can include
description of the feature in general).
Background: Used at the start of every scenario to
get to the point in the app where the feature is.
e.g. Listings feature, so background logs into the
app and gets to the listings grid.
Scenario: The scenario you require to test, should
be named exactly what it is testing.
Platform Folders(ios/ android/)
The platform folders contain sub
directories that are platform specific
items. These items can identify views,
helper methods and any pre-launch
methods required.
Helpers
Pages
Support
•
•
•
Platform Folder/Helpers
The Helper folder is to contain Ruby files which are
solely for platform specific methods.
A good example is entering text into a textfield will be
different in ios as it is to Android.
Here is the ios specific helper method:
Platform Folder/Pages
The pages folder contains files which
represent view controllers in our
application. These “page” files are
used to ensure that the test is on the
correct screen(“page”).
To do this, simply we define a trait
that is unique to the page. In most
cases it will be the main view with
an accessibility label set to the name
of the view controller.
PlatformFolder/Support
The support file is used to handle the before
and after running of scenarios. We can
change this file so that the app is reinstalled
after every scenario.
Playback
This folder contains actions that
recorded in the calabash console.
These actions are then referenced
in the feature file which in turn
performs the recorded action. This
playback function is handy for
scenarios where we need to move
a cell in a tableview.
Step Definitions
The step definitions contains the ruby files which map
to the BDD written in the .feature files.
Take note that Calabash have their own default steps
and we should use these where needed, if we have a
more custom scenario then use/create a file in the
folder page_name_steps.rb, if its a step used in many
pages then put this in the general_steps.rb
The default steps can be referenced here:
https://github.com/calabash/calabash-ios/wiki/02Predefined-steps
General_Steps.rb
In the general steps file, we should have methods that are generic and used
in multiple pages. A good example is being able to scroll a view in a
direction.
So this method will run the find_and_scroll_view method which exists in the
platform/helpers/utils.rb file. This means that when we scroll in android
or ios it will work. Not only will it work on any format, but also will work
with any BDD that matches the cases e.g.
•
•
Then I should scroll right on the listingsView
Then I should scroll up on the discoveryView
Both these BDD steps will run exactly the same code!
Support
This is the root support folder, which contains non-platform specific
actions/operations.
The env.rb file defines a variable of runstate, this variable is used in the
platform specific support folder called 01_launch.rb
So as a quick breakdown, the platform specific support file handles the
actual launch, but the general status(runstate) is held at a higher generic
level in the root support folder, this means we can create a 01_launch.rb
in the support folder for android and ios which contains their own way of
starting the simulator/emulators to run the app.
In addition to this, the support folder contains entry points for pages, this is
explained in detail in the next slide.
Entry_Points.rb
The entry points file contains the
generic methods used for pages. In the
screenshot, you can see the await
method is a commonly used method
for all pages. It lives in the entry
points file because all pages use it.
In the instance of a page using a custom
method, then you must create a file
pagename_entry_points.rb this file
will contain that method.
An example of a custom method could
be a method that checks the listings
grid for a cell.
Execution Structure
1. Feature file is broken down and
mapped to a step_definition, this can
also be the default calabash
step_definitions
.feature
step_definitions/
2. Step definitions then run
ruby code from either the
platform/helpers files or the
specific page methods e.g.
Listings.ScrollGrid
platform/helpers
3. Platform specific
methods which should be
interaction with platform
specific
elements(UIAlertView).
5. A page can call generic
methods in the helpers file. You
should expect to see the page
methods call several methods of
the helper file.
support/
platform/p
ages
4. The page file contains the
trait and any page specific
methods. e.g. ScrollGrid for
listings.
Quiz Questions
1: What is a step definition?
2: Why should I use a page file? and when?
3: If i want to make a view scroll, how would i do this?
4: What does the “background” text do when in a
feature file?
Quiz Answers
1: A step definition represents the binding between the BDD Gherkin and the ruby method needed
to run.
2: Page files are ruby files that represent the unique views in the application, they should be
used to ensure that a feature is on the correct screen and to run any view specific methods. We
should try to use page files when there is key functionality to be tested on a page, the methods
in the page file should be used to complete actions on the unique element, e.g. Scroll the
listings grid up, down, left and right. Or another example, jump to tomorrow in the grid.
3: If the view is fairly generic, you can achieve this by running the find_and_scroll_view method
in the helpers folder. If you want to complete more complex scrolling, say more than one type
of scroll then you should create a page file and call the scrolling method several times from
there.
4: The background element to a feature file is the steps ran before every scenario in that feature
file, we need to this because the application will be reinstalled and re-run after each scenario.
A good example would be testing the listings grid functionality, so when we run the feature, the
background method logs the application in and then proceeds to present the listings page, the
scenario can then concentrate on only testing listings functionality.