2009/11/5 Chuck van der Linden <[email protected]> > On Nov 4, 5:30 pm, David Chelimsky <[email protected]> wrote: > > On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <[email protected]> wrote: > > > On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <[email protected]> > wrote: > > > > > > Personally I now think nested steps are evil - but thats another > story :) > > > > > It sounds like an entertaining one. I'd love to hear why sometime. > > > (Though whether the right place for it would be here or the Cucumber > > > list, I couldn't say.) > > > > I'll pipe in since it's here on this list at the moment: > > > > I won't go as far as to say that nested steps are evil, but I don't > really > > like to use them myself because they do conflate two levels of > abstraction. > > I'd sooner have two steps delegate to a helper than one step delegate to > > another. > > > > FWIW, > > David > > > > I'll chime in also as to why I really dislike burying details like > that in the steps file. Nobody but dev plays around with the lower > layers and the step files in particular. Potentially everyone in the > business may have a hand in the 'feature' definition, or maybe need to > see or modify it at a later time. Also a Dev or tester reviewing > things to see 'how should it work' gets everything high level in one > place (the feature file) instead of having to chase down into multple > levels of step files ( an exercise reminding one of why we hate > spaghetti code) to find the details that matter up at the UI or > potentially integration test level. > > Remember Rspec/Cucumber are all about implementing BDD.. Part of BDD > is that more than just the folks in Dev will be looking at what's done > at the 'feature' level. If you bury the details of something inside > the step file, then nobody outside of dev can play along, and that > defeats a large part of the purpose of BDD. > > If it is important to the business that a particular field be on that > page, then you ought to have it expressed in the feature and not > buried in the steps. Consider something like > > 'Scenario: User reviews their profile details' > Given I am logged in as: <user> > When I click the link: view profile > Then I should see my profile details. > > How much more value to the business (and clarity to those implementing > the feature) is created if we were to instead have something more > like: > > .... > Then I will be on the page: User Profile > and I will see <field1> identified as <field1label> containing > <value1> > and I will see <field2> identified as <field2label> containing > <value2> > etc > > The <> items could either of course be spelled out, or they could be > parameters in a scenario outline's examples section. > > --Chuck > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users >
Couldn't agree less :-) , although alot of that depends on the business. There are many problems with the sort of scenarios you prefer 1) They are very fragile - change a label and it breaks. A business will review the application not the feature. When I change the label who fixes the feature, and why should I have to run 30 minutes of features to change one label! 2) You have to get detail correct before you know the context. As a business person how do I know what details should be in the user profile. 3) It places the responsibility for trivial and obvious decisions with the business people. And makes them make these decisions before they are ready. Its much easier to decide what should be on the profile page when you can see it and navigate to it. And as a business it is cheaper and far more effective to trust your development team rather than micro-manage them to the nth degree. 4) With an application of any size the amount of detail these type of scenarios generates soon removes and chance of the business actually reading or reviewing the features. Any chance of getting an overview of what the application does, or even readable reports of what works and what doesn't is lost. Dev's and testers are perfectly capable of looking at step definitions and working with them. Business people (at least the ones I know and have experienced) are much better at telling you want they want by providing feedback from the application itself than by doing any sort of up front work. One of the elegant parts of BDD is that by writing simple succinct features business can get you quickly into a feedback loop. It is much easier to create Feature As a user I want to have a profile So I can stop you spamming me Scenario When I view my profile I should be able to stop you spamming me and start iterating around that, than to create some big feature that specifies different labels for mailings and whether to use radio button or checkboxes. It is also much easier for the business to come back to a 5 line profile feature, and review this by looking at the application, than to review a 200 line profile feature. This is an Agile process we're supposed to be working with after all. All best Andrew
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
