[rspec-users] stepping across features

[James Byrne]

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 
algorithms?

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 
project.

Am I missing something obvious here?
-- 
Posted via http://www.ruby-forum.com/.