0 comments
Mobile Development 
A while back I started learning more about specification by example, because of my role as a proxy-product owner (I replace the product owner when he’s not around and spend a lot of time with him working out the specs for our application). He somehow managed to get me quite excited about it (Thanks Joop, you did it 
).
After he told me about specification by example a while back, I learned a lot more about its uses during development when I started exploring Calabash-Android.
Calabash-Android is a tool that you can use to run specifications with examples written in gherkin syntax files against your Android app. The tool reads gherkin files and combines them with step definitions built in Ruby to execute tests against the UI of your Android app.
Calabash is a great tool to use. It saved me a lot of time. Not only, because I am now able to automate a lot of the user interface testing that I otherwise had to do manually. It also made it possible for me to use those test specifications to write down what my system should actually be able to do/handle. It is the missing link between specification and testing of an Android or iOS app.
The only thing that it doesn’t have going for it is the documentation. It’s a bit messy, stuff is all over the place. This means that new-comers to this tool will find it hard to learn if they don’t know where to begin.
So in this post I will show you how to get started quickly and where you can find the information you need to get the most out of this tool.
Tip 1: Get familiar with the Ruby syntax
The tutorial for Calabash-Android describes how to write a basic test using a simple feature file and some pre-canned steps.
It’s easy, it’s fast and it’s very bad for you and your stakeholders.
Take this scenario that requires me to be logged on to an app using a valid twitter account built entirely using pre-canned steps:
Given I select item number 1
And I enter “my-user-name” into “username”
And I enter “my-password” into “password”
And I click “authorize”
When I select item “My workshop”
Then I should see “Work shop details”
To a programmer this makes sense. It describes exactly how to log on to twitter and execute the test scenario. There is a problem with this scenario. It is very verbose. There’s so much noise in there that a typical stakeholder doesn’t understand that the first 4 lines in this scenario aren’t all that important to the scenario. They are just there to establish a precondition for the actual test.
Building scenarios like this makes your specifications less usable to stakeholders. They are also less usable for you as a developer. What if twitter changes the inputs to usr, pwd and ok? I would have to check every scenario in my test set for these inputs and fix the scenarios.
The same scenario can also be built like this:
Given I am logged on as twitter user “tweety”
When I select item “My workshop”
Then I should see “Work shop details”
A lot simpler, however for this to work you’d need to build a custom step definition using the ruby syntax. Which is indeed a little harder when you just start out. But once you have the step defined, you can use it anywhere in your test scenarios. Which is a big win!
Here’s a few sources to get you going with the ruby syntax:
Be sure to check out tip 2 if you’re not that familiar with writing ruby or want to get the grips of the syntax without having to run your tests.
Tip 2: Use the interactive console to explore
Writing the right step definitions can be quite an annoying process if you’re not sure what query you should execute against your android UI.
There is a neat trick to make this process easier. Most command can be ran in the interactive calabash console. All you need to do is follow these steps:
- Start the Android emulator with the image of choice
- Build your app (in release mode)
- run calabash-android console <your-apk>
- Execute reinstall_apps in the interactive console
- Execute start_test_server_in_background
Now you can run commands against the currently active app on your emulator. The console will show you the results. You can even try to write more complex stuff with if statements on the console. It’s the best way to write new steps if you’re not that familiar with the calabash or ruby syntax.
Tip 3: Learn more about other Ruby libraries
The final tip is to learn more about ruby and the libraries that are available. You can do a lot more than just accessing the calabash API from your tests.
For example, you can deploy data to your app database right from a step definition using the ActiveRecord gem in combination with a SQL driver. This makes setting up date a lot easier if a backend system is involved.
Final thoughts
These are my tips to get started. I’d love to hear your personal experiences and tips!