sunomono 0.3.1 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 812541d3339c2da0aebd704bb947ff5440e66973
-  data.tar.gz: addd53f13c8d9b96203d7cddd9fad2c802800c35
+  metadata.gz: c2004c5b090a5d6ad75bba706b0b8ec7f56efc36
+  data.tar.gz: 4ffb96f15db0a129f681d89aa4d348f0e2eab48d
 SHA512:
-  metadata.gz: 33e7fca8f285101e3a1ae14130ba262536e65e4cc05263ee5aa1080b04f96ca60c2f6f4d76e2674b99149762c7a1fbcf2089c800e5aef3d61f44dc86df22aa48
-  data.tar.gz: 706956af6e7a3aeba067e01e10c41163dd8d4bfb2098985372ae85d58ccfd48f55ac901e2a14f46c578d4592f449df5fd0573df8e5c75734fd2d93ae27ca9ef5
+  metadata.gz: 3c1a32996b059a4ac2eac72bab7823f4856c955b62abd4e53901eaf9063d09cbdd19aca0ea287b9b288a6caf0de88da2ea52d13eb92fcbee24e8cd15e29d8d06
+  data.tar.gz: e4818940ec114d4f016f80080ec1ed4302cf07dd05aabedf2f6b1bce958e6486e319305795c94134e1e10b387fe37909edc21311071c8080310e5a4d3570ad34

data/README.md

@@ -4,25 +4,13 @@
 
 > ***The new version of [cs-bdd](https://rubygems.org/gems/cs-bdd) gem. cs-bdd was deprecated and will be yanked in the future. Always refer to sunomono from now on.***
 
-A simple gem to generate all files needed in a project that will support calabash for both Android and iOS.
+A simple gem to generate all files needed in a project that will support calabash and appium for both Android and iOS.
 
 iOS Build script works only with iOS SDK 9.2 or newer
 
-[Calabash](http://calaba.sh/) uses cucumber to support functional tests in Android and iOS and has one gem for each Platform:
+Sunomono(calabash) documentation : [(link)](https://github.com/concretesolutions/sunomono/SUNOMONO_CALABASH.md)
 
-  > calabash-android (for Android) [(link)](https://github.com/calabash/calabash-android)
-
-  > calabash-cucumber (for iOS) [(link)](https://github.com/calabash/calabash-ios)
-
-The project structure is based on [this site](http://rubygemtsl.com/2014/01/06/designing-maintainable-calabash-tests-using-screen-objects-2). The structure is based on three layers: features, steps and screens.
-
-  1. Features: Contains all the features of the project, this features are Platform independent and will run for Android and iOS tests;
-  2. Steps: Contains all the steps implementations. This steps are Platform independent and will run for Android and iOS tests;
-  3. Screens: Contains all the Android and iOS screens. A screen must contain an identification, the declaration of all the elements of the screen and the declaration of its actions. This layer is Platform dependent. This occurs because, in almost every project, the identification of the elements varies between the Platforms. One example is that in Android almost all elements have an id, but in iOS the most common is to identify the elements by accessibility label. The Platform dependent screens must have the same name and same methods signatures. This will allow your steps to be unique between platforms
-
-  > One example of this structure can be found in the generated files (see Usage) on the file base_steps.rb. This file implements some common steps to help you start your tests and show you how to uses the Platform dependent screens
-
-  > In my experience with tests I saw some cases that we will need to test features that are Platform dependent, like screens that send SMS which will only apper in Android apps. When this happen, the generated structure has Features and Steps that are Platform dependent and can be found inside the folder `features/android` and `features/ios` of the generated project.
+Sunomono(appium) documentation :  [(link)](https://github.com/concretesolutions/sunomono/SUNOMONO_APPPIUM.md)
 
 ## Installation
 
@@ -53,13 +41,19 @@ To see the gem version type:
 To generate a project that support both Android and iOS features type:
 
 ```
-  suno new ProjectName
+  suno new calabash ProjectName
+```
+
+or 
+
+```
+  suno new appium Project Name
 ```
 
 This command will create a folder named ProjectName in the current directory and will create all the needed files. This gem support localizations. To create a localized project, in Portuguese, type:
 
 ```
-  suno new ProjectName --lang=pt
+  suno new Framework(calabash or appium) ProjectName --lang=pt
 ```
 
 If you use Windows, to avoid encoding problems, run the following command in cmd:
@@ -91,13 +85,22 @@ There are nine generators that are responsible to create the templates for Featu
 ```
 The feature generator will create a Platform independent feature and its files. So this command will create the FeatureName.feature file inside the folder `feature`, the file FeatureName_steps.rb inside the folder `features/step_definitions`, the files FeatureName_screen.rb inside the folders `features/android/screens` and `features/ios/screens`.
 
+To create calabash based files:
 
 ```
-  suno generate android-feature AndroidFeatureName
-  suno generate ios-feature iOSFeatureName
+  suno generate calabash android-feature AndroidFeatureName
+  suno generate calabash ios-feature iOSFeatureName
 ```
-The aFeature and iFeature generator will create an Platform dependent feature. For example, the aFeature generator will create the AndroidFeatureName.feature file inside the folder `features/android/features`, the file AndroidFeatureName_steps.rb inside the folder `features/androd/step_definitions` and the screen file AndroidFeatureName_screen.rb inside the folder `features/android/screens`.
 
+To create appium based files:
+
+```
+ suno generate appium android-feature AndroidFeatureName
+ suno generate appium ios-feature iOSFeatureName
+
+```
+
+The aFeature and iFeature generator create a dependent feature for each platform. For example, aFeature generates the AndroidFeatureName.feature file inside the folder features/android/features, the file AndroidFeatureName_steps.rb inside the folder features/androd/step_definitions and the screen file AndroidFeatureName_screen.rb inside the folder features/android/screens.
 
 Don't forget about internationalization. All the generators accept the option `--lang=pt` or with some other language.
 
@@ -106,14 +109,14 @@ Don't forget about internationalization. All the generators accept the option `-
 ```
   suno generate step StepName
 ```
-The step generator will create a Platform independent step file named StepName_steps.rb in the folder `features/step_definitions`
 
+Another command creates an independent step file named StepName_steps.rb inside the folder features/step_definitions for each platform
 
 ```
   suno generate android-step AndroidStepName
 ```
-The android-step generator will create an Android step file named AndroidStepName_steps.rb in the folder `features/android/step_definitions`
 
+For Android, it creates a step file named AndroidStepName_steps.rb inside features/android/step_definitions
 
 ```
   suno generate ios-step iOSStepName
@@ -129,13 +132,68 @@ The iStep generator will create an iOS step file name iOSStepName_steps.rb in th
 ```
 The screen generator will create both Platform dependent screens in the folders `features/android/screens` and `features/ios/screens`.
 
+To create calabash based files:
+
+```
+  suno generate calabash android-screen AndroidScreenName
+  suno generate calabash ios-screen iOSScreenName
+```
+
+To create appium based files:
 
 ```
-  suno generate android-screen AndroidScreenName
-  suno generate ios-screen iOSScreenName
+  suno generate appium android-screen AndroidScreenName
+  suno generate appium ios-screen iOSScreenName
 ```
+
 The android-screen and ios-screen will create only the Android and iOS dependent screens respectively.
 
+## Load Classes
+**It works only calabash project**
+### Usage
+
+The load classes has been living in: 
+
+```
+  features/config/load_classes.rb
+```
+
+load_classes.rb provides a easy way to test your methods under development
+
+
+Use the calabash-android console mode 
+
+````
+  bundle exec calabash-android console  -p android feature/
+````
+
+or
+
+````
+  bundle exec calabash-ios console -p ios feature/
+````
+
+To load all .rb classes, run the following command on terminal
+
+````
+ load 'config/load_classes.rb'
+````
+
+Now you got all .rb files loaded
+ 
+Next step is to create a new instance of the class to test your methods
+
+```
+ @foo = page(fooScreen)
+```
+
+To use the methods, just call the method and enjoy 
+
+```
+ @foo.fill_data
+```
+
+
 ## Continuous Integration (CI)
 
 The project contains a lot of scripts that will help you to configure you CI server.

data/SUNOMONO_APPIUM.md

@@ -0,0 +1,18 @@
+# Sunomono Appium documentation
+
+[Appium](http://appium.io/) Appium uses Selenium to functional tests on Android and on iOS:
+
+The project structure is based on this [project](https://github.com/gricsi/cross-platform-appium-cucumber-test-example). The structure is based on three layers: features, steps, screens and modules. 
+
+
+  1. Features: Contains all the features of the project, this features are Platform independent and will run for Android and iOS tests;
+  2. Steps: Contains all the steps implementations. This steps are Platform independent and will run for Android and iOS tests;
+  3. Screens: Contains all the Android and iOS screens. A screen must contain an identification, the declaration of all the elements of the screen and the declaration of its actions. This layer is Platform dependent. This occurs because, in almost every project, the identification of the elements varies between the Platforms. One example is that in Android almost all elements have an id, but in iOS the most common is to identify the elements by accessibility label. The Platform dependent screens must have the same name and same methods signatures. This will allow your steps to be unique between platforms
+  4. Modules: Contains all the methods commons between the features e.g(LoginScreen(android) and LoginScreen(ios) contains the elements of the screens and different methods and interaction between platforms), the module contains the method with the same behavior on platforms
+  
+## Appium server
+  
+  RakeFile contains any tips to start the appium server and run your tests
+  
+  
+  

data/SUNOMONO_CALABASH.md

@@ -0,0 +1,19 @@
+# Sunomono Calabash documentation
+
+[Calabash](http://calaba.sh/) uses cucumber to support functional tests in Android and iOS and has one gem for each Platform:
+
+  > calabash-android (for Android) [(link)](https://github.com/calabash/calabash-android)
+
+  > calabash-cucumber (for iOS) [(link)](https://github.com/calabash/calabash-ios)
+
+The project structure is based on [this site](http://rubygemtsl.com/2014/01/06/designing-maintainable-calabash-tests-using-screen-objects-2).The structure is based on three layers: features, steps and screens.
+
+  1. Features: Contains all the project features,  which are Platform independent and will run for Android and iOS tests;
+  2. Steps: Contains all the steps implementations. These steps are Platform independent and will run for Android and iOS tests;
+  3. Screens: Contains all the Android and iOS screens. A screen must contain an identification, the declaration of all the elements of the screen and the declaration of its actions. This layer is Platform dependent. This happens because of, in almost every project, the identification of the elements varies between the Platforms. One example is that on Android most elements have an id, but on iOS  it’s common to identify the elements by accessibility label. The Platform dependent screens must have the same name and the same methods signatures. This will allow your steps to be unique between platforms
+
+  > One example of this structure can be found in the generated files (see Usage) on the file base_steps.rb. This file implements some common steps to help you start your tests and show you how to uses the Platform dependent screens
+
+  > In my experience with tests I saw some cases that we will need to test features that are Platform dependent, like screens that send SMS which will only apper in Android apps. When this happen, the generated structure has Features and Steps that are Platform dependent and can be found inside the folder `features/android` and `features/ios` of the generated project.
+
+

data/lib/helpers/sunomono_helpers.rb

@@ -58,6 +58,18 @@ def create_screen_file(name, platform)
            ), opts)
 end
 
+def create_appium_screen_file(name, platform)
+  # options used to generate the file in the template function
+  opts = { name: camelize(name), platform: platform }
+
+  # Thor creates a file based on the templates/appium_screen.tt template
+  template('appium_screen',
+           File.join(
+               FileUtils.pwd, 'features', platform.downcase, 'screens',
+               "#{name.downcase}_screen.rb"
+           ), opts)
+end
+
 def camelize(string)
   camelized = ''
 
@@ -134,3 +146,10 @@ def create_screen_shot_dirs(dir)
   Dir.mkdir File.join(dir, 'screenshots', 'ios')
   Dir.mkdir File.join(dir, 'screenshots', 'android')
 end
+
+def framework_avaliable?(framework)
+  if framework.downcase != 'calabash' && framework.downcase != 'appium'
+    puts 'Invalid framework choice calabash or appium'
+    exit 1
+  end
+end

data/lib/skeleton_appium/Gemfile

@@ -0,0 +1,8 @@
+# Gemfile to help setting up the initial development environment
+source 'https://rubygems.org'
+
+gem 'appium_lib'
+gem 'appium_console'
+gem "cucumber"
+gem 'sunomono'
+gem 'pry'

data/lib/skeleton_appium/features/support/android/appium.txt

@@ -0,0 +1,4 @@
+[caps]
+    platformName = "Platform name e.g Android"
+    deviceName = "Device name e.g Nexus_5 or device ID"
+    app = "path to apk"

data/lib/skeleton_appium/features/support/env.rb

@@ -0,0 +1,21 @@
+require 'pry'
+require 'appium_lib'
+require_relative File.expand_path('../../base_screen/base_screen.rb', __FILE__)
+
+
+# Class to not pollute 'Object' class with appium methods
+class AppiumWorld
+end
+
+if ENV['PLATAFORM'] == 'android'
+  caps = Appium.load_appium_txt file: File.expand_path('../android/appium.txt', __FILE__), verbose: true
+else
+  caps = Appium.load_appium_txt file: File.expand_path('../ios/appium.txt', __FILE__), verbose: true
+end
+
+Appium::Driver.new(caps)
+Appium.promote_appium_methods Object
+
+World do
+  AppiumWorld.new
+end

data/lib/skeleton_appium/features/support/ios/appium.txt

@@ -0,0 +1,5 @@
+[caps]
+    platformName = "plataform name e.g =  iOS"
+    platformVersion = "platform version e.g = sdk version"
+    deviceName = "device name e.g iPhone 6"
+    app = "path to apk or ipa"

data/lib/skeleton_calabash/.gitignore

@@ -0,0 +1,9 @@
+.irb-history
+reports/*
+test_servers/*
+.DS_Store
+screenshot*.png
+screenshots/android/*
+!screenshots/android/.*
+screenshots/ios/*
+!screenshots/ios/.*

data/lib/skeleton_calabash/README.md

@@ -0,0 +1,165 @@
+#Getting Started 
+
+## Ruby
+  
+  There is a lot of ways of installing ruby, one is using RVM (http://rvm.io/rvm/install):
+  
+  Install RVM stable with ruby: 
+
+  ```
+  $ \curl -sSL https://get.rvm.io | bash -s stable --ruby
+  ```
+  
+  After this, include the following lines in you `~/.bashrc` file.
+  
+  ```
+  export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
+  [[ -s $HOME/.rvm/scripts/rvm ]] && source $HOME/.rvm/scripts/rvm
+  ```
+
+# Android
+
+## Installing the Gems
+
+  Install the following gems
+
+  ```
+  gem install calabash-common calabash-android
+  ```
+
+  **Warning!**
+  
+  The gem **`calabash-android`** can install the beta version of the cucumber gem.
+  This gem brokes the execution of the calabash. After the installation of calabash-android, check your installed gems with the command `gem list | grep cucumber` and install the stable version of the cucumber gem (command: `gem install cucumber`) and remove the beta version (command: `gem uninstall cucumber`), if that is the case.
+
+## Running the tests
+  To run the android tests, you need to:
+  
+  1. Open the Android AVD
+  2. Open the terminal on the tests folder
+  3. Execute the command:
+  
+  ```
+    calabash-android run features/app-QA.apk -p android
+  ```
+  
+
+  > To run in a computer with more than one emulator or device, use the command:
+  >
+  >```
+  >  ADB_DEVICE_ARG=emulator-5554 calabash-android run features/app-QA.apk -p android
+  >```
+  >
+  >Given that 'emulator-5554' is one of the returns of the command `$ adb devices` on the terminal
+
+
+  > To run on all connected devices, run the script `run_tests_all_devices.sh`, located on the `config/scripts/android` folder of the project
+
+  > **!! IMPORTANT !!** 
+
+  > Remember to export the WORKSPACE variable with the path of the cloned test repository
+  
+  > Remember to pass the APK path as the parameter of the script
+  > 
+  > ```
+  > ./config/scripts/android/run_tests_all_devices.sh PATH_OF_APK_FILE
+  >```
+
+
+## Calabash Terminal
+
+The calabash terminal allows you to run the calabash commands without being on a test context
+To open the calabash terminal, you need to:
+
+  1. Open the Android AVD
+  2. Open the terminal on the tests folder
+  3. Execute the command:
+  
+  ```
+    calabash-android console features/app-QA.apk -p android
+  ```
+  
+  4. Run the commands
+  
+  ```
+    reinstall_apps
+    start_test_server_in_background
+  ```
+  
+  5. Run the commands you want to.
+
+# iOS
+
+## Installing the Gems
+
+  Install the following gems
+
+  ```
+  gem install calabash-common calabash-cucumber
+  ```
+  
+## Configuring the iOS project
+
+  1. Run the command `pod install`
+  2. Run the command `calabash-ios setup` and follow the instructions
+  3. Make sure that the signing is a wildcard
+
+
+## Running the tests
+  To run the iOS tests in a device, you need to:
+  
+  1. Open the terminal on the tests folder
+  2. Compile the project to create the .app file with the command 
+  
+  ```
+  ./config/scripts/ios/build_app.sh xcworkspace_path TargetName-cal iphoneos8.1 ConfigurationName
+  ```
+  
+        PS.1: TargetName-cal is the name of the target created with the command `calabash-ios setup`
+        PS.2: iphoneos8.1 is the sdk for devices, for emulatores use iphonesimulator8.1
+        PS.3: Configuration name can be Dev, Debug, Release, Prod or any other configuration build
+        PS.4: The path to the .app file is the last output line of the above command
+
+  3. To execute one feature, run the command
+  
+  ```
+    APP_BUNDLE_PATH=AppFilePath DEVICE_TARGET=DeviceUUID DEVICE_ENDPOINT=CalabashServerEndpointDevice cucumber -p ios
+  ```
+  
+  4. To execute all the features in the configured devices run the script
+  
+  ```
+    ./config/scripts/ios/run_tests_all_devices.sh AppFilePath
+  ```
+  
+      PS.: Remember to configure all the connected devices on the file `./config/scripts/ios/devices`.
+           In this file you need to inform the device UUID, the device IP with the calabash server port and a name to identify this device on the reports. Remember to leave an empty line at the end of the file and to split the informations using pipes.
+
+## Calabash Terminal (Device)
+
+The calabash terminal allows you to run the calabash commands without being on a test context
+To open the calabash terminal, you need to:
+
+  1. Connect the device
+  2. Open the terminal on the tests folder
+  3. Execute the command:
+  
+  ```
+    APP_BUNDLE_PATH=AppFilePath DEVICE_TARGET=DeviceUUID DEVICE_ENDPOINT=CalabashServerEndpointDevice calabash-ios console
+  ```
+  
+  4. Run the command
+  
+  ```
+    start_test_server_in_background
+  ```
+  
+  5. Run the commands you want to.
+
+## Pitfalls
+
+  1. Always build the project with the device connected
+  2. Ensure that the device is enabled to Development and the UI Automations is enabled on the Developer menu (Settings)
+  3. If the device in pin locked, ensure that it is unlocked. If there is no pin, the calabash will automatically unlock the device
+  4. Ensure that the device WIFI is enabled and it is accessible from the computer that is starting the tests. The calabash server works sending commands to the device by the network.
+  5. Always run the target -cal on the Xcode one first time to see if the target is ok and running. The calabash-ios gem cannot print errors of execution, but Xcode can.

data/lib/skeleton_calabash/config/cucumber.yml

@@ -0,0 +1,7 @@
+# config/cucumber.yml
+##YAML Template
+---
+android: PLATFORM=android SCREENSHOT_PATH=screenshots/android/ -r features/support -r features/android -r features/step_definitions --exclude features/ios
+
+
+ios: PLATFORM=ios SCREENSHOT_PATH=screenshots/ios/ -r features/support -r features/ios -r features/step_definitions --exclude features/android

data/lib/skeleton_calabash/config/email/template.html

@@ -0,0 +1,14 @@
+<html>
+  <head>
+    <meta charset="UTF-8">
+    <title>Project Name - Sunomono _OS_ - _STATUS_TITLE_</title>
+  </head>
+  <body>
+    <center>
+      <h1>Continuous Integration</h1>
+        <h2>Job Status: _JOB_NAME_, build number: #_BUILD_NUMBER_</h2>
+        Hello. I'm here to let you know that the tests <strong>_STATUS_</strong>.<br>
+        To view the reports, click <a href="http://jenkins_url/reports/_JOB_NAME_/_BUILD_NUMBER_">here.</a><br>
+    </center>
+  </body>                                                                                                                                  
+</html>

data/lib/skeleton_calabash/config/scripts/android/run_tests_all_devices.sh

@@ -0,0 +1,41 @@
+#!/bin/bash
+# ----------------------------------------------------------------------------
+# Uncomment the next line to enable debug
+# set -x
+#
+# $1 -> parameter with the name of the apk
+# $2 -> parameter to indicates the tapume to run. Can be null and can have other 2 values: must or should
+
+## CODE BEGIN  #############################################################
+[ $# -lt 1 ] && echo "Wrong number of parameters." && exit 1
+
+# Counting the number of lines returned from the command adb devices
+# This command will return at least 2 as result, because of one header line and one empty line at end
+# So if the result is less than or equal 2, it means that there are no devices or emulators connected
+number_of_devices=$(adb devices | wc -l)
+[ $number_of_devices -le 2 ] && echo "There are no devices or emulators connected!" && exit 1
+
+echo Inicio da execução: $(date)
+
+# Creating the reports folder for the html format
+reports_path="$WORKSPACE/reports-cal"
+mkdir $reports_path
+
+for device in $(adb devices | grep "device$" | cut -f 1)
+do
+  cd $WORKSPACE
+  # Creates the reports folder
+  mkdir "$reports_path"/"$device"
+
+  {
+      ADB_DEVICE_ARG=$device calabash-android run $1 -p android SCREENSHOT_PATH="$reports_path"/"$device"/ -f 'Calabash::Formatters::Html' -o "$reports_path"/"$device"/reports.html -f junit -o "$reports_path"/"$device"
+      # Calabash has a problem with images relative path, the command above will replace all the images path on the
+      # html report file to be a relative path
+      sed -i.bak 's|'"$reports_path"/"$device"/'||g' "$reports_path"/"$device"/reports.html
+  }&
+
+done
+wait
+
+echo Fim da execução: $(date)
+## CODE END  #############################################################

data/lib/skeleton_calabash/config/scripts/android/start_emulators.sh

@@ -0,0 +1,52 @@
+#!/bin/bash
+# Author: Victor Nascimento
+
+bash stop_emulators.sh 
+
+# Suffix name of the AVD
+SUFFIX="CALABASH_AVD_4."
+
+# All $SUFFIX emulators are started
+for AVD in ${HOME}/.android/avd/${SUFFIX}*.avd
+do
+    # remove any locks that were left
+    rm "$AVD/*.lock" 2> /dev/null
+    # takes only the name of the AVD
+    echo $AVD
+    AVD="$(basename ${AVD/.avd/})" 
+    echo starting "$AVD"... 
+    emulator -wipe-data -gpu on -noaudio -scale 0.5 -no-boot-anim -accel on -avd "$AVD" -qemu -m 1024 -enable-kvm &
+done
+
+sleep 15
+# lists all emulators with adb and check for its online state
+
+# finds the port through adb emulator name
+for porta in $(adb devices -l | grep ^emulator | cut -d " " -f 1 | cut -d - -f 2)
+do
+    echo Searching for emulator PID for port: ${porta}
+    pid=$(netstat -tlnp 2> /dev/null | grep "$porta" | tr -s " " | cut -d " " -f 7 | cut -d "/" -f 1)
+    echo gets the AVD name from the exec command
+    avd=$(ps -ef | grep -v grep | grep "$pid" | egrep -o '\-avd .*' | cut -d " " -f 2)
+    echo AVD: ${avd}
+    # if name contains suffix
+    if echo "$avd" | grep -q "$SUFFIX"
+    then
+	echo Waiting for "emulator-${porta}:${avd}" to be ready
+
+	# Wait for online state with maximum 60 tries
+	COUNT=0
+	
+	while adb -s "emulator-${porta}" shell getprop dev.bootcomplete | grep -q error 
+	do
+	    if [ "$COUNT" -eq 60 ]
+	    then
+		echo "Emulator took too long to start up"
+		exit 1
+	    fi
+
+	    let COUNT++
+	    sleep 1
+	done
+    fi
+done