Mobile Software Test Automation: Generating a Calabash project

Last week, we finished up the sections on dependencies, and now we are ready to start building a project!  Before we start writing actual automated tests, we need to generate the appropriate directory structure and supporting files for the test to run.

Generating Calabash Project

You are hopefully a little more familiar with the command line at this point, so I won't go through the same remedial steps that we have been.  First, cd into your project folder. Then, you will need to run:

$ calabash-android gen

You will then need to press enter/return at the prompt. It should look something like this:


You could have also used calabash-ios gen and the results would be the same.  Inside your project folder, it will generate a features folder with the file structure as seen below:


For a single platform test suite, this structure won't be a problem.  However, for a cross-platform test suite, the project should look a little different.  Here is a snapshot of what a cross-platform project should look like:


I have removed a few of the auto-generated files, but this should give you a good idea of what the project structure should look like, which brings me to the next topic...

Project Structure

We will have a high-level discussion this week about the structure and what each part is, and then over the next couple weeks I will give more in-depth information for each.

.feature file(s)

This file (or files) is the highest level of your test script.  These are test steps written in Gherkin, which is a human-readable domain specific language.  We will get more into this next week.


This folder should house all of your step definitions, which are the code pieces that are tied to the steps outlined in your .feature file.  


You will notice that the pages folder didn't exist in the auto generated model.  This is because for a single platform test suite, they are not needed, as steps can be defined explicitly for that platform.  However, for a cross-platform model, the step definitions need to be generic enough to cross both platforms, and then the page support files explicitly define a test for each platform.  These files are essentially the code that hooks your step definitions to the specific app under test.

support (platform specific)

Similar to the page support, there is a support folder for each platform.  The support folders hold the ruby source code that is, in part, responsible for running the step definitions.  Basically, these files control things like the launching of the app, when a screenshot is taken, if a reset of the application is needed, and so on.  As we get more in-depth, I will also put out some code for this that I have created, which will launch an emulator if no device is attached, wake up and unlock a device, and some other fun stuff.  But for now, I want to get you rolling with your project, so ill table that until later.

support (the other one)

This folder can house files with non platform specific code, which both tests can use.  I mainly use it to store all my test data (usernames, passwords, numbers, etc.), which makes it much easier to modify when needed.  

And that wraps everything up for this week.  Next week we will get the project structure set up with a sample project, and then we will start writing the acceptance tests, with a more in-depth discussion on Gherkin to follow.