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

Andrew Premdas apremdas at gmail.com
Fri Nov 7 10:41:57 EST 2008


Joseph,

Thanks for your reply, much appreciated.

The scenarios don't have titles just for this discussion. Felt including
them would be a distraction.

I agree that some of the Givens should be Whens in these examples e.g.

  Given I step to customer
  When I fill in my customer details incorrectly
  Then I should see an error

I've read the Ben Mabey article many times its great. Thats where I got the
declarative and imperative terms from.

I'm not doing any javascript testing yet, I'l put screwunit on my toread
list.

The depends on the customer answer is an interesting one. In this case I am
the customer (and the developer) and I'm not sure :).

I quite like and have used scenario tables a number of times. In this case
though I feel that they would pollute the feature. Its as if I want two
levels of features, high level ones to test the overall wizard behaviour,
and low level ones to test each screen. The tables would be highly
appropriate in the lower level tests. I do wonder though if edge cases
really belong in features. I think of them as more of a developer than
customer concept. However the tables make it really nice to write plain text
low level (dare I say unit) features, which have the benefit of clearly
documenting intention in a way that any other test mechanism I've seen so
far cannot.

The brain dump is much appreciated and helps

Cheers

Andrew

2008/11/7 Joseph Wilk <josephwilk at joesniff.co.uk>

> 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
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081107/ecbca180/attachment-0001.html>


More information about the rspec-users mailing list