User Acceptance Testing tutorial on Zucchini: part 1: Getting Started

  I am about to embark on the challenge of self-educating myself on iOS UAT (User Acceptance Testing), and hope to publish as a series of tutorials, my findings, right from starting up to how run tests. I will also investigate Calabash and other alternatives, in the process, so hang in tight.

The yucky veggie

Once in a while programmers like us get some great ideas, but a lot of brilliant ideas start up in the business chain, and cascade down to us developers as sets of translated instructions for coding. The idea behind the cucumber framework lies in creating simple ideas that even business-minded people can construct, in simple English and almost use it as is, or UAT. Hence, the premise for the creation of this framework is born.


Instead of a business stakeholder passing requirements to the development team without much opportunity for feedback, the developer and stakeholder collaborate to write automated tests that express the outcome that the stakeholder wants.

These tests are different from unit tests, which are aimed at developers and help them to drive out and check their software designs. It’s sometimes said that unit tests ensure you build the thing right, while acceptance tests ensure you build the right thing. (The Cucumber Book, M.Wynne & A.Hellesöy, 2012)

It is Acceptance Testing (AT) in ubiquitous language readable cross-departmentally , backed by a class in a language called  Coffee-Script, as opposed to Calabash which is written with Gherkin (more on that in later tutorials), which is used to convert the code into javascript.  The following is a snippet (from the Zucchini framework site) that shows the natural language to describe the walkthrough of your apps:

Structural overview


The Process

We first start off by creating a feature (that is the screenshot above), stored as a file, describing the contextually different screens in your app.

The feature is then backed by a Coffee-Script class, which wires all the UI elements that you want your feature to interact with, in addition to extending the class with custom actions.

class PostScreen extends Screen
  anchor: -> view.navigationBars()["Post"]

  constructor: ->
    super 'post'

    extend @elements,
    'Post': -> view.navigationBars()["Post"].buttons()["Post"]

    extend @actions,
    'Type "([^"]*)"$': (text) ->
      messageArea = view.elements()['Message Text Area']
      messageArea.setValue text

The point of the class is, it will convert your intentions into Javascript, in fact a UIAutomation-compliant Javascript that then leverages Apple's CLI Instruments tool to run the simulator and take the screenshots. Quite nifty huh!


Getting started, and installing

The following is straight out of the Zucchini homepage, but I'll cut and paste it here:


Zucchini only runs on Mac OS X 10.6 and 10.7 and requires XCode 4.2 as well as Ruby (at least 1.8.7).

The other two dependencies are ImageMagick and CoffeeScript. If you use Homebrew, they are straightforward to install:

brew update && brew install imagemagick && brew install coffee-script


Adding Zucchini to your project

Install the zucchini-ios gem:

gem install zucchini-ios


Create a project scaffold for zucchini:

zucchini generate --project /path/to/my_project


Create a feature scaffold for your first feature:

zucchini generate --feature /path/to/my_project/features/my_feature

And next...

There is a sample project for you to play around with, until my next tutorial, which will dive into Zucchini in greater-detail.
[learn_more caption="Link" state="open"]https://github.com/rajbeniwal/zucchini-demo[/learn_more]