Android Functional Testing Using Calabash – Part Two

Introduction

In my previous post, we explored the reasons behind Behaviour Driven Development (BDD) and using Calabash as the tool to implement achieve this methodology.  We also began applying Calabash in the form of implementing a Feature using the gherkin syntax/DSL.  In this next chapter, we’ll look at applying (or implementing custom) steps defined in out Feature file.

Chapter Three – Steps

In this chapter, we’ll be looking at Step definitions used in our Feature file.  As a reminder, here is our Feature file from my previous post:

@register
Feature: Registration feature

@register-successful
Scenario: As a new user I want to register a new account
    Given I have entered an email and password
    When I press the Register button
    Then I should see a progress indictor
    Then I wait for a toaster message 'Success'
    Then I should see the roster

Calabash comes with a bunch of pre-defined steps to get you started.  But, in the event that you need to expand on the available steps, you can define your own (hint: use the pre-defined steps are examples).  Steps in Calabash are expressed as Ruby and defined in *_steps.rb files.

But, what if I have custom widgets (e.g. custom login email and password EditText views)? How do I reference this widget?  The one thing you may have noticed is that UI elements are addressed similarly to CSS.  So, let’s leverage this:

Given /^I enter an email and password$/ do |text|
 clear_text_in("com.mitchwongho.demo.calabash.widgets.CustomEmailEditText id:'email'")
 enter_text("com.mitchwongho.demo.calabash.widgets.CustomEmailEditText id:'email'", "someone@example.com")
 clear_text_in("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'")
 enter_text("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'", "Str0ngP@ssworD")
end

In my next post, we’ll explore how to go about testing the features beyond the login screen.

 

Android Function Testing Using Calabash – Part One

Introduction

It’s too often that app development projects are run without a solid chain/link between Requirements → Development → QA/Testing, where testing is neglected or performed manually.  The key to effective QA is Automation.  Autonomous testing can be achieved via unit testing for algorithms and UI (instrumentation) testing for functional testing.  Traditional UI/functional testing is achieved by using Android’s UIAutomator API.

The purpose of this post is to illustrate how functional testing can be achieved using Calabash/Cucumba.

The Agile Alliance states that one of the benefits of BDD (Behaviour Driven Development) over TDD (Test Driven Development) as:

BDD offers more precise guidance on organizing the conversation between developers, testers and domain experts.

However, I do think that BDD can be used to complement TDD.

The premise for using Cucumber is to develop functional tests using natural language that all stack-holders, technical and non-technical, can understand and this fits in well with the agile software development methodologies that use User Stories to define the behaviour of the system between user and app (software).  BDD translates easily from User Stories: The more comprehensive the User Stories, then more comprehensive your functional tests.  Further more, BDD tests can be written by the business analyst defined the User Stories, developer or QA engineer.

Calabash enables you to write and execute automated acceptance tests of mobile apps. Calabash is cross-platform, supporting Android and iOS native apps. It is open source and free, and has a company, Xamarin, backing and developing it.

Chapter One – Calabash

Calabash/Cucumber consists of a server component and a client component.  The Server component is a Ruby application that interprets the Feature and Step definition files to drive an Instrumentation Test Server that is installed on the test device/emulator.

Calabash Android Architecture

Instructions to download and install Ruby and Calabash-Android are found here.  Once you have installed Ruby and Calabash, you may proceed on to the next chapter.

Chapter Two – Features

As explained in the introduction, Calabash is based on Cucumber to deliver a framework with which to define Features ala User Stories using natural language as the test cases.  To illustrate this, we’re going to use the scenario that we’re developing an Instant Messaging app and as with any project, there is a stage in the process where requirements are gathered.  Let’s take this opportunity to define our first Story aka requirement:

“As a new user I want to register a new account, so that I may interact on the social network.”

Calabash Features, by convention are simple text files with the ‘.feature’ extension that reside in the ‘features/’ folder.  Let’s have a look at our first Feature (register.feature): 

 

@register
Feature: Registration feature

@register-successful
Scenario: As a new user I want to register a new account
    Given I have entered an email and password
    When I press the Register button
    Then I should see a progress indictor
    Then I wait for a toaster message 'Success'
    Then I should see the roster

That’s it!  We’ve defined out first Feature.  There a number properties that are illustrated in out first attempt here:

–  Firstly, we name/describe our feature using the ‘Feature:‘ attribute on line 2.
–  Secondly, we identify our scenario using the ‘Scenario:‘ attribute (notice how we’ve used the same description as our Story declaration), followed by the test steps required.  These can be considered the prerequisite(s), requirement(s) and then acceptance-criteria of the scenario.
–  Lastly, we illustrate the use of @tags. We use these to mark points-of-reference.

At this point, if you tried running this feature, you’d get a bunch of Calabash error.  That’s because Cucumber doesn’t know how to interpret out scenario steps.  We’ll explore that in part two.

 

Android Protip: Copy a SQLite database

Disclaimer: NO Root access required

Sometimes you need to export your app’s SQLite database to your computer for further analysis. Seeing that there isn’t a ‘cp’ command, this is how you’d go about doing it:

adb shell ‘run-as com.my.package cat /data/data/com.my.package/databases/mydb.sql > /sdcard/mydb.sql’

 

Top 10 Performance Techniques for Mobile Web Apps

Christophe Coenraets (Adobe technical evangelist) did a great talk on Top 10 Performance Techniques for PhoneGap Mobile Web Apps (link)

I thought I’d quickly outline the techniques discussed in his talk

#10 Don’t generate the UI at the server-side
– Create the UI in javascript at the client-side
– Insert views into- or remove from the DOM

#9 Don’t wait for the data to display the UI
– Perception management
– People will wait for data, not for UI

#8.1 Cache static data
– LocalStorage / SQLite

#8.2 Cache Dynamic Data
– Present cached data first, then
– update UI when requested data arrives

#8.3 Cache JS query selectors
– assign selectors to avoid traversing the DOM repeatedly
– Coding convention tip: prefix ‘$’ to selector variables e.g ‘var $backButton’

#8.4 Cache Precompiled templates

#7 Use CSS transitions with hardware acceleration
– (CSS) transform: translate3d()
– micro-library: https://github.com/ccoenraets/PageSlider

#6 Avoid ‘Click-Event 300ms’ Delay
– micro-library: FastClick : https://github.com/ftlabs/fastclick

#5 Use CSS Sprites
– ala Glyphicons

#4 Limit use of shadows and gradients

#3 Avoid reflow (re-layouts)
– Build UI off-DOM then apply

#2 Do you need that framework?

#1 Test. Test. Test
– Test with production data
– Test with many devices
– test with bad networks