18. it’s the manager’s job to
keep projects on
schedule
twitter: bphogan
email: brianhogan at napcs.com
19. it’s the passionate
programmer who fights
for quality.
twitter: bphogan
email: brianhogan at napcs.com
20. and the client is paying
you to build something.
twitter: bphogan
email: brianhogan at napcs.com
21. so what can we as
developers do to solve
these issues?
twitter: bphogan
email: brianhogan at napcs.com
22. we need to grab
requirements from our
customers easier...
twitter: bphogan
email: brianhogan at napcs.com
23. we need to make
testing fast and easy...
twitter: bphogan
email: brianhogan at napcs.com
24. and it needs to be part
of the schedule.
twitter: bphogan
email: brianhogan at napcs.com
25. domain experts first
and code second.
twitter: bphogan
email: brianhogan at napcs.com
26. Feature: creating a new page in the wiki
As an average anonymous user
I want to create a page about Cucumber
So that I can tell everyone how awesome it is.
Scenario: Creating a new page and editing its content
Given I go to "/Cucumber"
Then I should see "Edit this page"
When I click "Edit this page"
And I fill in "body" with "Cucumber is the best way to test apps!"
And I press "Save"
Then I should see "Cucumber is the best way to test apps!"
twitter: bphogan
email: brianhogan at napcs.com
27. features, not
requirements.
twitter: bphogan
email: brianhogan at napcs.com
28. features are value
propositions.
twitter: bphogan
email: brianhogan at napcs.com
29. focus on features that
have real business
value.
twitter: bphogan
email: brianhogan at napcs.com
30. As a...
I want to...
So that I can...
twitter: bphogan
email: brianhogan at napcs.com
31. Feature: creating a new page in the wiki
As an average anonymous user
I want to create a page about Cucumber
So that I can tell everyone how awesome it is.
twitter: bphogan
email: brianhogan at napcs.com
32. Feature: creating a new page in the wiki
As an average anonymous user
I want to create a page about Cucumber
So that I can help people improve the quality
of their sites with automated testing.
twitter: bphogan
email: brianhogan at napcs.com
33. Given Then
When
twitter: bphogan
email: brianhogan at napcs.com
34. scenarios describe the
feature in detail.
twitter: bphogan
email: brianhogan at napcs.com
35. Given
setups, preconditions,
prerequisites
twitter: bphogan
email: brianhogan at napcs.com
36. Given
Scenario: Creating a new page and editing its content
Given I go to "/Cucumber"
twitter: bphogan
email: brianhogan at napcs.com
37. When
describe actions
twitter: bphogan
email: brianhogan at napcs.com
38. When
When I click "Edit this page"
And I fill in "body" with "Cucumber is the best way to test apps!"
And I press "Save"
twitter: bphogan
email: brianhogan at napcs.com
39. Then
describes outcomes
twitter: bphogan
email: brianhogan at napcs.com
40. Then
Then I should see "Cucumber is the best way to test apps!"
twitter: bphogan
email: brianhogan at napcs.com
41. this process helps you
get the app designed.
twitter: bphogan
email: brianhogan at napcs.com
42. these stories can then
be run against live
code!
twitter: bphogan
email: brianhogan at napcs.com
43. step definitions use
Ruby code and regular
expressions to run
stories.
twitter: bphogan
email: brianhogan at napcs.com
44. but you can run stories
against any web-based
application
twitter: bphogan
email: brianhogan at napcs.com
45. Web
Application
Testing
In
Ruby
twitter: bphogan
email: brianhogan at napcs.com
46. Then I should see "Welcome to the site!"
Then /I should see "(.*)"/ do |text|
@browser.text.should include(text)
end
twitter: bphogan
email: brianhogan at napcs.com
47. When I fill in "username" with "bphogan"
When /^I fill in "([^"]*)" with "([^"]*)"$/ do |field, value|
twitter: bphogan
email: brianhogan at napcs.com
48. your clients and
managers don’t need to
know HOW these
work
twitter: bphogan
email: brianhogan at napcs.com
49. they just need to
remember a few
keywords.
twitter: bphogan
email: brianhogan at napcs.com
62. constant
communication.
twitter: bphogan
email: brianhogan at napcs.com
63. questions?
http://github.com/napcs/cucumber_watir
twitter: bphogan
email: brianhogan at napcs.com
Hinweis der Redaktion
It’s easy to blame clients. Sometimes it’s fun, too. But we are the professionals and we have to come up with ways to explain things better. They are experts in their fields.
I’d bet these two things lead to most project failures.
Start with bad developer practices... testing can be frustrating.
we’d rather be coding new features, and users would rather have a product that works well and not have their time wasted doing the developer’s job for them.
managers don’t want developers to take longer than necessary. Pushing features faster is more important than spending time writing tests.
We don’t do things that are hard and not fun. It’s just human nature. We just kind of hide and pretend they’re not problems.
People lose jobs over buggy software. Especially in the banking, public safety, and health insurance sectors.
First, start thinking of communicating features and testing your apps as part of your job security.
We can make the work easy by automating things. We spend so much time as developers automating processes for our clients that we never stop to think about how we might do that for ourselves and our processes.
We can reduce some of our work if we can get the users involved in a real way.
Finally, in order for this to work, management has to enforce testing practices. Applications have to be shipped with good test coverage, and time estimates must include the time it takes to write tests.
Unfortunately, every single developer can come up with a list of excuses why they don’t test enough. Usually they blame management or marketing for pushing deadlines. And clients like to blame you for not building what they want,
Management has to make deadlines or stuff doesn’t get done, and they have outside forces pressuring them to deliver results.
You know programming, you know how hard it can be, and you know the penalties for testing. You need to make your case for it, and you have to prove it won’t kill the time schedule.
You answer to them. They may not always be right, but they help pay your bills. We’d all be out of jobs if it weren’t for the customers.
We can use Cucumber to gather requirements from clients, and create automated tests from those stories.
We write stories in plain English to help communicate the ideas behind the feature.
Talk about features. Requirements can’t be postponed. Clients can continue to add features. Developers can work with clients to re-evaluate features.
When thinking about a feature, you and your user must think about what value the feature has.
Ask yourselves “why do we need this feature? How will having this feature benefit a user?” The user might be a system administrator, a site owner, a basic user, or an anonymous guest, but you should only think about features that directly impact a user.
A feature can best be described by filling in these blanks: “As a somebody, I want to do something, so that I can do something else.
You describe a scenario using “given, when, then”.
The scenario describes the feature in more details, explaining how a user will move through the application to achieve the feature’s goal.
“Given” steps explain the prerequisites for the test. They let you specify any setup conditions that must have occurred outside of the process. Set up records, processes, etc.
Scenario: Creating a new page and editing its content
Given I go to "/Cucumber"
“When” steps describe what you do during the scenario
When I click "Edit this page"
And I fill in "body" with "Cucumber is the best way to test apps!"
And I press "Save"
“Then” steps describe the outcome you expect.
Then I should see "Cucumber is the best way to test apps!"
If you and your clients build these stories together, you can easily design the functionality and describe the interface.
Even though we write these definitions in Ruby code, you can run Cucumber against anything that shows up in your browser, including Flash!
WATIR, or “Web Application Testing In Ruby” automates Internet Explorer or Firefox and works well with Cucumber.
The stories you write live with the code, because you test your code with the stories you write.
Let’s write a Cucumber story to search for Cucumber information with Google’s advanced search.
Pivotal Tracker!
Difficulty is determined by your team based on how complex the feature is. Estimation is key to success.
We can use Pivotal’s API to push and pull Cucumber stories.
Velocity is really how many units of work you can handle in an iteration.
Bugs don’t get points. They count against your velocity.
This approach makes you focus on delivering new features for your customers.
As they keep asking for things, they can see them adding up. You can then discuss how you continue to make deadlines.
Each horizontal line represents a point where we had to move a release - because a person wasn’t contributing.