[rspec-users] features and form filling - going declarative?

Joseph Wilk josephwilk at joesniff.co.uk
Fri Nov 7 05:47:43 EST 2008


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 fred at example.com <mailto:fred at example.com>
>        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 fred at example.com <mailto:fred at example.com>

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 fred at example.com,'  ' 
<mailto:fred at example.com>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




More information about the rspec-users mailing list