Building the Mobile App Function Automation Platform from 0 to 1 (4) : Automation test code, “Engineering Nation”

In Ruby, the first thing that comes to mind when you think of testing is Minitest or RSpec, the two most commonly used testing frameworks in Ruby. With these frameworks, we can manage Ruby test cases very well.

Similarly, since our automated test scripts are written in Ruby, we can also use Minitest/RSpec to manage our automated test cases.

Based on this idea, we used RSpec to initialize the engineering structure of the previous system login test case. For those of you who are familiar with Ruby programming, or who have some code background, it is natural to initialize the test case framework with the following structure.

├ ─ ─ Gemfile ├ ─ ─ android │ └ ─ ─ appium. TXT ├ ─ ─ common │ ├ ─ ─ the requires the rb │ └ ─ ─ spec_helper. Rb └ ─ ─ ios ├ ─ ─ appium. TXT └ ─ ─ The spec └ ─ ─ login_spec. RbCopy the code

In Gemfile, you specify the libraries that the project depends on.

source 'https://gems.ruby-china.org'
gem 'rspec'
gem 'appium_lib'
gem 'appium_console'Copy the code

In common/spec_helper.rb, the simulator and RSpec initialization code are defined.

def setup_driver
  return if $driver
  appium_txt = File.join(Dir.pwd, 'ios', 'appium.txt')
  caps = Appium.load_appium_txt file: appium_txt
  Appium::Driver.new caps
  end
def promote_methods
  Appium.promote_appium_methods RSpec::Core::ExampleGroup
  end
setup_driver
promote_methods
RSpec.configure do |config|
  config.before(:each) do
    $driver.start_driver
    wait { alert_accept }
  end
  config.after(:each) do
    driver_quit
  end
  endCopy the code

In common/requires. Rb, references to related library files are implemented.

require 'rspec'
require 'appium_lib'
require_relative 'spec_helper'Copy the code

The ios simulator information and test package path are configured in ios/appium. TXT.

[caps]
platformName = "ios"
deviceName = "iPhone 6s"
platformVersion = "9.3"
app = "/Users/Leo/MyProjects/AppiumBooster/ios/app/test.app"Copy the code

In the ios/spec/ directory, this is the content of the test case. For example, ios/spec/login_spec.rb corresponds to the system login test case.

Based on the above, our first transformation task was to separate the test case from the control mapping.

Considering that there are only a few commonly used control manipulation methods (click, type), we can encapsulate control manipulation methods as a separate module as a public module.

module Actions
  def click
    wait { @found_cell.click }
  end
  def type(text)
    wait { @found_cell.type text }
  end
  endCopy the code

Then, each page in APP is encapsulated as a module, the controls in the page are mapped as static methods of the module, and the method module is introduced through include mechanism.

For example, the login page could be wrapped in the following code.

module Pages
  module Login
    class << self
      include Actions
      def field_Email_Address
        @found_cell = wait { id 'txtfieldEmailAddress' }
        self
      end
      def field_Password
        @found_cell = wait { id 'sectxtfieldPassword' }
        self
      end
      def button_Login
        @found_cell = wait { id 'btnLogin' }
        self
      end
    end
  end
  end
module Kernel
  def login
    Pages::Login
  end
  endCopy the code

A bit of Ruby metaprogramming is used here, which is to encapsulate the page module as a method and add it to the Kernel module. The advantage of this is that we can manipulate the control anywhere in the project directly through login. button_login. click.

After the above modification, the system login test case can be written in the following format.