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:
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'", "email@example.com") clear_text_in("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'") enter_text("com.mitchwongho.demo.calabash.widgets.CustomPasswordEditText id:'password'", "Str0ngP@ssworD") end
In my next post, we’ll explore how to go about testing the features beyond the login screen.