In my previous article I explained why it is not a bad idea to use Cucumber as an automation tool. In this one I’ll show using the real example how it works. Also we will get closer to mobile automation, as for the sample project I will use Calabash iOS and Android. You’ll ask why Calabash and not Appium? The answer is simple – I just like this tool. Later I’ll publish article series about iOS mobile automation tools evaluation, where I’ll compare KIF, Appium, XCUITest, EarlGrey and Calabash.
The fact, that this example is based on Calabash, doesn’t mean that you will be unable to apply the same approach to another tool. This approach is not locked by one particular technology.
So, less words more actions. Let’s start with the sample project. You can find the project here: https://github.com/JoeSSS/SampleWaysOfTesting
The project contains Calabash project itself and two applications to test, one for Android and another for iOS. Calabash project is structured in such a way that one test will work for both iOS and Android. In tests I’ll use page objects and reusable step definitions.
If you have your mobile infrastructure in place, the project should work out of the box. The only thing you’ll need is to run `bundle install`. If you haven’t worked with mobile projects before, you’ll have to install:
- Xcode for iOS
- Android instruments for Android
- Ruby > = 2.2.0 (2.3.1 is recommended)
More information about setting up your environment you can find here:
Test are running from the console.
To run all the iOS tests :
bundle exec cucumber –p ios
To run one particular iOS test :
bundle exec cucumber –p ios ––t @sample_1
To run all the Android tests:
bundle exec cucumber –p android
To run one particular Android test:
bundle exec cucumber –p android ––t @sample_1
RubyMine is a really good IDE for writing Cucumber tests. The main advantages in comparison to another tools are the following:
#1 It has auto completion for Cucumber. That is really helpful when you have a lot of step definitions.
#2 You can jump through the methods that makes debugging easier.
Classes and methods accessibility
In order to see all the classes, methods and page objects from the tests I use cucumber.yml. It requires all the files from directories that you specify in the yml file. Also, yml configuration file allow you to require different files for iOS and Android tests.
Page objects are very useful. Using them, you can reuse one object in different tests without duplicating the code.
iOS page objects for this sample project are here.
Android page objects you can find here.
As you can see page objects represent addresses of the element using classes, text, ids or their combinations as well as hierarchy dependencies.
There is an example of
checkButton address using class
UIButton and text “Check the number”:
class WelcomeScreen < BasePage
"UIButton marked:'Check the number'"
You can access this object from every place of your test simply calling:
Step definitions are the translations of your Gherkin steps to a programming language. So, when you are calling a step like:
And I tap on WelcomeScreen.checkButton
It will be translated into:
Then(/^I tap on ([^\"]*)$/) do |element|
path = get_path element
Tags can be added to each test. You can give a unique tag to a test and then run the test using this tag. (e.g.
bundle exec cucumber –p ios ––t @sample_1). Also you can add behavior to a specific tag, for example add a tag @reset_simulator and then implement the simulator reset function in your “before” method.
There are two similar one-view applications for Android and iOS. In this application you can enter data and check if this data is an Integer. If data is integer you’ll see the green label with confirmation; if data is something else you’ll get the red label with an error massage; if data is empty you’ll get the yellow label with the call to provide the value.
Using Cucumber in your tests
Tests live in .feature file. When opening the feature file, you can see how I reuse steps to create 3 different tests without making them look like documentation. So, instead of using one complex step for each test, I use several reusable steps that you can apply to any other test you’ll write afterwards. That is true, that readability is going down, but that allows me to write other tests reusing same page objects and steps without duplicating the code. For example, you can try different inputs; clicking on other elements; double clicking and etc. without writing anything but changing page objects, input and colors in step definitions.
Now when you have general knowledge about the project, try to launch it and write your own scenario! Believe me, it is easy.
As you may have noticed, this article was aimed to introduce you in the sample repository. In my next articles I will explain this more detailed, based on this sample project that I’ll constantly enlarge.