Stepping Into BDD with Cucumber and WebRAT: Structuring the Work
This is the first of a series on my adventures in going BDD with Cucumber and WebRAT with a greenfield project. Watch for the next article coming soon.
I’m working on a tiny project for the dads club at my son’s school and using the opportunity to plunge fully into BDD with Cucumber. I’ve been tinkering with it a bit here and there, but this time I’m committing to fully specifying my acceptance criteria before I start writing specs for my implementation. I have to admit it feels a bit onerous right now, but I can see the value coming so I’m sticking to it.
My usual working methodology is:
- Write a quick set of use cases
- Infer features from the use cases
- Divide the features into logical delivery phases
- Start spec’ing the implementation
- Code to the specs
… so really I’m just adding a “Specify features using Cucumber” step between 3 and 4. Sounds small (but it’s not).
The use cases for this project are pretty easy:
Use Cases: NON-MEMBERS: * Join MEMBERS: * See news postings * See calendar events * Subscribe to a calendar feed * Read and send email to the group * Maintain a member profile (email, phone, location, kid info, etc.) * Browse and search a member directory (by grade, class, proximity/map, etc.) PREZ FOR LIFE: * Write news postings * Post new events * Send news/reminders to various publishers (group mailing list, school newsletter editor, etc.)
(Yeah, we have a President For Life. He’s awesome.)
Time to break these into features. I try to scope each delivery to be a useful increase in features and something I can delivery quickly (I don’t get much geek time these days ;). Some of this is old hat (it’s mostly just a CMS), but some of it calls for me to learn about things I’ve never played with (Google Maps APIs and Geolocation, for example). Additionally, it was important to get something up fast last week so the main URL could be included in some printed materials for back to school week.
Here’s the feature rough divided into phases:
Phase 0: Site Non-Members can see front page Phase 1: Members Non-Members can join Members can sign in with email and password or OpenID PFL can manage news items PFL can manage events PFL can manage pages PFL can suspend accounts of non-PFLs Members can view news and events News snippets and event titles show on top page Phase 2: Admins Members can be made admin by PFL Admins can manage news items Admins can manage events Admins can manage pages Phase 3: Feeds and Mailings Members can subscribe to news and events feeds PFL can set reminders to be sent by email Members can recover passwords by email Phase 4: Profiles Members can add email, phone, address, availability, notes, profile pic Members can add kids: name, age, picture, teacher Members can mark info private, admin-only, or open Phase 5: Directory Members can browse directory info Phase 6: Maps Members can see people, events on map
Phase 0 was “get something up fast;” we made it a simple redirect to the existing Google group. Phase 1 is the biggest chunk of features, but they’re very straightforward. Each phase after that introduces enough new functionality to be interesting for the members, but in small enough chunks that I should be able to knock ‘em out in a weekend, plus-or-minus.
Okay, so now I’m ready to generate the app and cucumber-ify it. I’ll cover that in the next article.
blog comments powered by Disqus