1 / 17

Calabash Structure

Calabash Structure. Andrew Reed. File Structure. Config/ cucumber.yml Features/ android/ ios/ playback/ step_definitions/ support/ *.feature files. Config. In the config directory we have a single configuration file(cucumber.yml)

kiral
Download Presentation

Calabash Structure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Calabash Structure Andrew Reed

  2. File Structure • Config/ • cucumber.yml • Features/ • android/ • ios/ • playback/ • step_definitions/ • support/ • *.feature files

  3. 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.

  4. 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.

  5. .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.

  6. 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

  7. 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:

  8. 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.

  9. 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.

  10. 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.

  11. 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/02-Predefined-steps

  12. 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!

  13. 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.

  14. 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.

  15. Execution Structure 3. Platform specific methods which should be interaction with platform specific elements(UIAlertView). 1. Feature file is broken down and mapped to a step_definition, this can also be the default calabash step_definitions platform/helpers 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. .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/pages support/ 4. The page file contains the trait and any page specific methods. e.g. ScrollGrid for listings.

  16. 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?

  17. 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.

More Related