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