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 <[EMAIL PROTECTED]> > 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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
