Writing Cucumber

Readability and Maintainability
Writing Good
Cucumber Well

Readability
Maintainability
Features/Scenarios
Step Definitions
Data Objects
Page Objects
TestFactory
Watir
Selenium
Ruby

● Feature
● Summary
● Scenario
Cucumber’s Parts

● Feature
● Summary
● Scenario
Cucumber’s Parts
“What is the point?”
“Why is this a feature?”
“Who is going to care?”

● We are all QA
● If it’s not readable no one will read it
● “Living” requirements documentation
● Ubiquitous language
Theme: Effective Communication
Why “Readable” Cucumber?

Write a scenario without thinking about...
● User Interface
● The needs of the Ruby code
Instead, pretend you’re talking to a SME
(Be okay with getting it wrong the first time, because you will)
The Basic Approach

Ask yourself this question:
“If the entire system were scrapped and re-written
from scratch, what is the likelihood that this
Feature/Scenario would survive in its present form?”
The Basic Approach

Unit Tests
● Fields allowing certain character sets
● Select lists containing expected values
● Document IDs unique
User Interface Tests
● Element alignments
● Usability considerations
Performance Tests
● Page loading
● Server calls
Cucumber is not suited for...

I create a proposal
Declarative versus Imperative
I go to the login page
I enter my user name
I enter my password
I click the login button
I click the “Create Proposal” link
I click the “expand all” button
I type “Title” in the title field
I select “New” in the Type selection list
I type “00340” in the Sponsor Code field
I type today’s date into the Start Date field
I type tomorrow’s date into the End Date field
I click on the save button
...

I create a proposal
Declarative In Detail
in the BL-BL unitwith a 5-year budgetwith a Federal sponsorwithout a PIstarting next yearhaving a sponsor deadline

Given a particular system
state
When a specific event
occurs
Then a new state is
expected
● Everything needed for the
test/requirement to be valid is
spelled out concisely
● Everything not needed is left
out
● The point is explicit
● The expected/desired outcome
is comprehensible
● Remember that the user has
some goal in mind--some
reason for using the software
Given/When/Then

Scenario: Create Proposal with Invalid Sponsor
Given a user exists with the role Proposal Creator
When the proposal creator creates a proposal with an invalid sponsor
Then an error should say that a valid sponsor is required
Scenario: Adding an F&A rate to an Award
Given a User exists with the role Award Modifier
And the Award Modifier creates an Award
When the Award Modifier adds an F&A rate to the Award
Then the default start and end dates are based on the F&A rate's fiscal year
Scenario: Protocol submitted to a Committee with submission date restrictions
Given users exist with the roles IRB Administrator and Protocol Creator
And the IRB Admin submits a committee with events scheduled before and after its adv
submission days setting
And the Protocol Creator creates an IRB Protocol in the committee's home unit
When the Protocol is being submitted to the committee for review
Then the earliest available schedule date is based on the committee's Adv Submission Days value
Examples - Scenario Title

Given I am logged in as "@PersonX@"
And I attempt to view the portal page
When I access the Project Code maintenance document
And I fill in a random Description
And I fill in a random Project Name
And I fill in a random Project Description
And I fill in a random Project Code (and remember it)
And I set Project Manager Principal Name to "@project_code.project-manager-principal@"
And I set Chart Code to "@project_code.chart-code@"
And I set Organization Code to "@project_code.org-code@"
And I submit the document
And I acknowledge the document as "@project_code.reviewer1@"
Then it should go to a Final Status
Example - Yikes!

Given I am logged in as "@PersonX@"
And I set Project Manager Principal Name to "@project_code.project-manager-principal@"
And I set Chart Code to "@project_code.chart-code@"
And I set Organization Code to "@project_code.org-code@"
Example - Yikes!
Only “@PersonX@”???
Seems like this, and the other “@” lines are
sneaky bits of code, which is a no-no at the
Scenario level!

Given I am logged in as an Administrator
And I set Project Manager Principal Name to a Project Manager
And I set Chart Code to a valid chart code
And I set Organization Code to a valid org code
And I acknowledge the document as the first reviewer
And I acknowledge the document as the second reviewer
Example - Yikes!

Example - Yikes!
How do you code for an “attempt”?
Why is “viewing” the portal page
important for this scenario?

Example - Yikes!
What is the pivotal, state-changing
event in this scenario?

And I access the Project Code maintenance document
When I acknowledge the document as the second reviewer
Example - Yikes!

Example - Yikes!
Why isn’t every bit of data in the test
being remembered automatically?
Is it really important to explicitly state
this stuff in the scenario?
Also, these steps seem dangerously
vague. Will they always work?

Example - Yikes!
Same goes with all of
these guys.

And I submit a new project code maintenance document
Example - Yikes!

Example - Yikes!
What should go to a final status?
Remember, step definitions are
“global.”

Then the project code maintenance document’s status should be final
Example - Yikes?

Example - Getting better
Not bad! But it can still be better...

Given an Administrator submits a new project code maintenance document
When first and second reviewers acknowledge the project code maintenance document
Example - Ahhhhh... Much better

● Cucumber adds value when abstracted from the code
● Scenarios should:
○ Model user behavior
○ Validate something important to the user
● Avoid:
○ Excessive detail and specificity
○ UI references (“click”, “field”, “page”, etc.)
○ Being too generic
● Final thought: Read The Cucumber Book
Summary

Writing Cucumber

More Related Content

Viewers also liked (8)

Similar to Writing Cucumber (20)

Writing Cucumber