Tag Archives: BDD

Android Functional Testing Using Calabash – Part Two


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:

Feature: Registration feature

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'", "")
 clear_text_in("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'")
 enter_text("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'", "Str0ngP@ssworD")

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

1 Comment

Posted by on March 12, 2015 in Android


Tags: , ,

Android Function Testing Using Calabash – Part One


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

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): 


Feature: Registration feature

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.

1 Comment

Posted by on March 9, 2015 in Android, QA


Tags: , , ,

Unit Testing for Android – Mockito

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?).

I see unit testing being used in two ways: first, for algorithm/logic validation and secondly, for behavior validations (BDD – Behavior Driven Development).

In this post, I’m just going to illustrate how to use Mockito to validate algorithms/logic at unit(method)-level on an Android application.

The Ingredients

The following libraries are required in your test project’s classpath:

  • Mockito (as of this post mockito-1.9.5)  – link
  • DexMaker (dexmaker-1.0 and dexmaker-mockito-1.0) – link
As of 1.9.5, Mockito supports the Delvik VM by using DexMaker to generate
mock classes dynamically, allowing the unit test to run on your android 

The Preparation

Test Subject

Suppose our app stores data in a SQLite database while offline. Once the app is connected, it can sync with the server.

public void syncData( final ConnectionManager connectionManager )
    final NetworkInfo networkInfo = connectionManager.getNetworkInfo( ConnectivityManager.TYPE_WIFI );
    if ( networkInfo.isAvailable() && networkInfo.isConnected() ) {
        //...sync data

Test Case Structure

When using Mockito, I find it useful to follow the Setup/Exercise/Verify pattern:

  • Setup – Setup the stub/mock objects and their behavior
  • Exercise – invoke the method(s) to tests
  • Verify – Verify that the stubs/mock objects were interacted with as expected
public class TestApplication extends AndroidTestCase {
public void testSyncData() {
    // Setup
    final ConnectivityManager connectivityManager = Mockito.mock( ConnectivityManager.class );
    final NetworkInfo networkInfo = Mockito.mock( NetworkInfo.class );
    Mockito.when( connectivityManager.getNetworkInfo( ConnectivityManager.TYPE_WIFI ).thenReturn( networkInfo );
    Mockito.when( networkInfo.isAvailable() ).thenReturn( true );
    Mockito.when( networkInfo.isConnected() ).thenReturn( true );
    // Exercise
    syncData( connectivityManager );
    // Verify
    Mockito.verify( connectivityManager ).getNetworkInfo();
    Mockito.verify( networkInfo ).isAvailable();
    Mockito.verify( networkInfo ).isConnected();

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.


Posted by on April 24, 2013 in Android


Tags: , , ,