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:

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

I recently worked on an Android app that used the device’s only USB I/O port to control another piece of hardware. This requirement eliminated my ability to use LogCat or debug the application…until I discovered that you can use ADB over wifi.

Unit testing in general is one of the after thoughts for many during the development process. I was recently reminded how important unit testing is and that it should seriously be considered when estimating time/effort during the project planning/estimation day(s) in your Agile process (you are Agile, right?).

The Execution

The final step is the run the testcase as a Android JUnit Test. You’ll notice that a ‘Test’ APK is built and installed on your device and presents a non-destructive way of testing applicable behavior on specific devices.

Once you work more with the Mockito API, you’ll see just how powerful this tool is and how you’ll benefit from better application code structure, architecture and reliability.

In a future post, I’ll discuss how Robolectric will speed up our testing cycles.