Matt, Thanks for reply much appreciated and very helpful
I'm definitely feeling a need/desire to write features at different levels as you say, and in this case I am trying both, though I haven't quite worked out a nice way of organising things as yet. I definitely want to seperate my 'noisy' from 'quite'. In the example I gave the noisy version would have things about blank names as well as invalid emails. I'd probably use a scenario table, and might even include checks for the content of error messages. I just put a small part in the example to give a flavour. I do think this is a bit of an art discussion. Its a credit to cucumber that we can have such discussions as I think it has cracked most of the science part, which for such a young tool is really impressive. I think that the art of organisation is a key element in expressing intention clearly. If something is in the right place is much easier to find out what it is trying to do. Maybe there is a need for a feature hierarchy in the same way there is a test heirarchy ... All best Andrew 2008/11/7 Matt Wynne <[EMAIL PROTECTED]>: > 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 > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
