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] <mailto:[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?
I'm not sure if you where just giving examples but its always a good
idea to give your scenarios titles. Scenario titles generally describe
what is different between the other scenarios.
Also your Given 'And' steps feel a little like thens (Its generally a
good idea to avoid talking about user interaction in givens [1] unless
they happened earlier):
>And I fill in email with [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
So to ensure that it is clear 'filling in the email' happened in the
past I would write it as:
And I have filled in email with 'email'.
I've tried both combinations as your mentioned. I think one of your
questions is what is better:
declarative steps - 'And I fill in my customer details incorrectly'
imperative steps - 'And I fill in email with [EMAIL PROTECTED],' '
<mailto:[EMAIL PROTECTED]>And I fill in name "Fred Bloggs"'
Ben Mabley has written a great article on imperative vs declarative
steps [2] which is a great read.
I don't think there is a 'best way', It really depends on your
customer. What is really important to them (be it that you might be
mocking the role of the customer) and how would they express it. Is this
a form which is payment/login and is fundamental to the business. If so
the customer may want to express the scenarios in detail.
If its a hugely complex form which would leave your with a massive
number of steps at a low level it might (each customer is different) be
hard to read and provide a lot of noise over the true value.
> # add table for different combinations of form fields that cause
errors
> # consider checking that errors are appropriate
Mentioning actual values in scenarios means you can take advantage of
scenario tables. They allow your to test edge conditions without having
lots of scenarios which is great!
Something I've been trying out is dropping in and out of different
levels of abstraction in your scenario. For example:
@@@
Scenario: Bad passwords
Given I filled in the form with the essential valid details
And the password was entered as 'blah'
When ...
Then I should see 'error'
| password | error |
| womble | No wombles allowed as password |
| password | Terrible password |
@@@
I've found so far that customers really like this. It is a nice way it
pull out the really interesting part to the customer and leave the other
details (that are often noise) at a higher level. And it also means you
can use Scenario tables to exercise edge conditions.
WDYT?
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).
When it comes down to JavaScript form validation I have started to test
these using screwunit [3]. As for controller based validation and errors
I use specs. Error messages can play such a fundamental part in a site
that I'm always keen on having some spec tests at the controller level
for them. While these test can be a little brittle, I've seen too many
error messages get changed or mangled.
I also test forms and error ouput in Features. But more than 'test a
form' I'm really testing a user value holds and it just so happens that
this value is achieved through some form process. Its also important to
remember that features cross cut through the whole application stack
when testing unlike my spec tests.
Sorry thats a bit of a brain dump, I hope it provides you with some
helpful info.
:(|)
Joseph Wilk
--
http://www.joesniff.co.uk
[1] http://github.com/aslakhellesoy/cucumber/wikis/step-organisation
[2]
http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/
[3] http://github.com/grockit/screw-unit-server/tree/master
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
