James, If this is the case then to do BDD well you have to simulate the dialogue between customer and developer. At the moment you are so thinking like a developer so you are starting with detailed technical features rather than general customer features. Also you're using such complicated language, I feel you really should make the effort to simplify right now.
One tip that might be useful is to be very clear with your language and find better names. If you need adverbs and adjectives to clarify your verbs and nouns, then your verbs and nouns aren't good enough. Client is not a good name for an emphemeral role. If you need adverbs and adjectives to clarify your verbs and nouns, then your verbs and nouns aren't good enough. I'm not convinced that Entity is a particularly good name either the fact that you need so many words to specify what it is = bad smell. Now if you use replace Entity with Client, then you have Clients who you represent. Each client has a history. The history consists of 'periods' when you represented them (haven't found a good word for that yet) 'term' might be reasonable but I'm sure there is some proper legal term perhaps related to contract. Anyhow use whatever resources you can and find single words if you can or hyphenated words if you really have to As for your features they can start super simple Feature: Clients should have a history Given there is a client When I view the client And I select history I should see the client history So now you can create your client, rails model with a name field and a route. Create your history - probably could do this with just a route and a controller, and a view that says 'history'. Now iterate! Feature: Client_Histories should have 'terms' Given there is a client When I view the client history I should see terms Iterate again Feature: Terms should have starts, ends and one client Iterate Feature: Terms should be made dormant when ... After each step you implement you think about the language and the sense of the thing you've just done and quickly review. If it doesn't make sense refactor. If you do this for the core things you have in your applications you will have something working and visual to then think about things like authentication and feature organisation which you really want to address only when you need to. One of the fundamental ideas about Agile software is that each iteration is an opportunity for learning, because each iteration gives you feedback. If you do small iterations then you get back small chunks of feedback which you can learn from easily. If you do big iterations you get one big chunk of feedback impossible to fully digest and most likely to be just ignored. As you are mostly working on your own here you can get started now. Use BDD to explore your business domain and produce a stupidly primitive (fundamental? foundational?) features and application, you might just end up with a firm foundation to build your application on. Final tip, start with nouns, ignore verbs for as long as possible. e.g think about 'clients', but don't think about 'adding'. When you've got a whole bunch of nouns together then you'll have enough context to make working the verbs much easier. Seems I've gone on another 'rant'! Thanks for inspiring this James, I've enjoyed thinking about these things, I can only hope they have some value for you. All best Andrew 2009/2/23 James Byrne <li...@ruby-forum.com> > Stephen Eley wrote: > > > > > ...So that's my reality. Cucumber for collaboration isn't the value > > for me. I suspect that there are a *lot* of companies out there with > > one-person IT departments that may fit into my situation, and > > certainly a whole ton of personal projects where there was never any > > money or 'business case' in the first place. In those cases, > > communicating features to "the customer" is just talking to oneself. > > It may still have value, but it isn't about teamwork. > > > > Anybody else in a situation like this? > > > > In essence that describes my situation. The difference being that I do > have a user (one) who will sit down and work through a feature (the > first time and then only briefly). There are others who get to comment, > particularly on issues of nomenclature, but none that have the time and > inclination to make the sort of effort taken for granted in BDD. > > I see cucumber as way to document my intentions and use the scenarios as > discussion points with others in my firm. The great advantage is that I > can then use cucumber to drive what I call testing which, in turn, > drives coding. The resources do not exist to support much more than > that. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > 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
