[rspec-users] stepping across features
apremdas at gmail.com
Fri Dec 5 01:01:44 EST 2008
I think this is where the art or craft comes in. Features are a great tool,
but being such a great tool I think its very easy to become tempted to
overuse them. People in software keeps on looking for the silver bullet.
They find something new, overuse it, become frustrated by it, move on to
something else and the cycle begins again. From this comes alot of
innovation, but also alot of frustration and waste.
The second point I'd like to make is that testing is really hard. IMO its
much harder than writing functionality so you can expect to struggle. And
its not just about actually getting things tested, but its also about
- deciding what to implement
- deciding what to test
- deciding how to test
- organising your tests so they communicate your intention clearly
- cover your functionality
... (lots more)
All software projects are entropic. That is if you don't put a continuous
input of energy into them they will become chaotic. You can use features to
counter this chaos to add order to your project or you can just use them to
test things. If you use them just to test things your missing out though on
their fundamental purpose which is to express clearly what the intention of
a project is with a secondary benefit of providing a mechanism to execute
those intentions and see if they are met.
So back to your original question where does all the detail go? Well
acceptance tests start from the general and go to the specific, so detail
comes further down some sort of heirarchy. Thing is you haven't got a
hierarchy yet so you don't know where to put things. I'm in a similar
situation with the code I'm working on and its real tempting to start
putting in all that detail in the features, but I'd suggest really trying
hard to avoid that. Basically if you need detail refactor your feature so
that you don't and create new scenarios to deal with the detail only when
you have to. In the end you can have most of the detail in your step
definitions and use the nesting of steps to build more complex stories.
I've put my example app on github. It has a refactoring of the
restful-authentication stories following these principles, perhaps it will
give you some ideas
2008/12/4 James Byrne <lists at ruby-forum.com>
> I need a bit of instruction. I have spent the day reading online
> bloggs, tutorials, and howtos relating to BDD, RSpec and testing. I
> have also spent several hours going through the cucumber spec/test
> suites in an attempt to absorb some sense of how best to proceed. I am
> somewhat nonplussed.
> Here is my situation. I am the domain expert (together with a few
> others) and I am the business analyst and I am the systems analyst and I
> am the coding team. So, I am essentially in the position of having to
> interview myself (mostly) to write specifications so that I can design a
> system that I will have to code, myself.
> I have spent the better part of the last two years learning ruby and
> rails, taking related courses, investigating, acquiring, installing and
> learning to use various support tools like Subversion, which I have
> since replaced with GiT, and Trac project administration system, which I
> have since replaced with Redmine. I also beat my head against a brick
> wall trying to get some idea on how to use rspec stories to facilitate
> my initial foray into TDD which then evolved (for me) into BDD.
> Along came cucumber and in the space of a few days I have begun to write
> and run actual tests derived from features that I have described in a
> cucumber fashion. I have actually written working code driven by
> feature requirements. Heavens, I have even "refactored" my initial step
> definitions to remove instance variables and create cross feature steps.
> I now have rcov reports telling me what tests need to be written for the
> code I already have. Things seem good.
> Where do I go from here? At issue for me is really how much detail goes
> into the features. It was pointed out that the present form of many of
> my features betray a "programming" bias. I admit to this. My question
> is: Where does one specify the nitty gritty details of what columns go
> into what relations that possess what associations with what other
> relations? Where does one put the descriptions of business rules and
> These are all examples of user driven details to at least some degree.
> I mean, not every client management system need distinguish between an
> operating name and a full legal style and yet keep both for the same
> customer. So this is a detail that I feel should be expressed from the
> user pov somewhere. Tax calculations and fee discount structures are
> also areas that need user driven expression. Do these not belong in
> features too?
> I can see that features deal with high level stuff. But there is an
> awful lot of low level details that end users have to specify as well.
> Even if they do not need to know about database normalization or
> attribute naming conventions they nonetheless have to express,
> somewhere, their need to retain full addresses, postal codes of varying
> format depending on country, telephone numbers, perhaps categorized into
> meaningful classes, and the like. Where are these requirements
> expressed if not in features? Presumably one must test to see that the
> requisite information is retained and retrievable even if exactly how is
> not explicitly stated in their requirements.
> I had, at one point, the idea that, at least in the beginning, I would
> do most of this detail expression in the form of feature steps. The
> advice I have received has caused to reflect on whether this is a
> desirable course to take. However, I can see no obvious alternative
> other than to bury the design requirements in rspec specs or testunit
> tests, both of which seems to defeat the idea of having users drive the
> Am I missing something obvious here?
> Posted via http://www.ruby-forum.com/.
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users