On 7 Nov 2008, at 06:09, Andrew Premdas wrote:
I'm working on writing features for a wizard. The wizard collects
information from a number of different forms, and you can navigate
through it in a number of ways. Anyhow one of these forms is a
customer form collecting name, and email.
In the context of the wizard I feel that the following scenarios
Scenario:
Given I step to customer
And I fill in my customer details correctly
Scenario:
Given I step to customer
And I fill in my customer details incorrectly
Then I should see an error
are preferable to
Scenario:
Given I step to customer
And I fill in email with [EMAIL PROTECTED]
And I fill in name "Fred Bloggs"
Given I step to customer
And I fill in email with ''
And I fill in name "Fred Bloggs"
Then I should see an error
# add table for different combinations of form fields that cause
errors
# consider checking that errors are appropriate
note: Given I step to customer is nested step doing all sorts to
get to the form
What do you think?
Good questions! You're getting into some pretty subtle stuff here, and
it's hard to even articulate what I think about it as it's changing
all the time as I get more experience working with cucumber.
I guess as Joseph has said, you want to balance out keeping the noise
down in the feature without hiding away important information about
the desired behaviour.
One technique is to have a single noisy 'declarative' scenario that
explicitly walks around filling things in, then all the rest use more
'imperative' style steps where most of the detail is buried away. I
think, and I know that this sounds wishy-washy, you need to try out
both and see how they feel to you.
In the example you gave, I where the specification seems be be about
valid email addresses, I would probably make my step something like
this:
Given I step to the customer stage of the wizard
When I fill in a valid name
And I fill out an email address "blah"
Then I should see an error
Thereby hiding the irrelevant "Fred Bloggs", but surfacing the
important "blah"
I'm looking for some input on this, and in particular am wondering
where should I put the more specific tests for form validation,
error messages etc. in my test hierarchy, or even if I should test
them at all (could you argue they're in built rails functionality).
Hmm....
Again, this is getting from science to art. I think you need the
features to tell you whether the whole things hangs together (e.g. can
the form display a validation message at all?), but when you start to
iterate more tightly with specific examples of a valid / invalid
object, I that's where I would drop into unit tests and write code
examples against the model object (or whatever you use for validation).
Having said that, I'm putting more and more specification into
cucumber features - the more steps you write, the more you build up a
re-usable language for describing your system, the easier it gets.
Make any sense? Does that help at all?
cheers
Matt
http://blog.mattwynne.net
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
