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:

  1. Write a quick set of use cases
  2. Infer features from the use cases
  3. Divide the features into logical delivery phases
  4. Start spec’ing the implementation
  5. Code to the specs
  6. Profit!

… 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:

* Join

* 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.)

* 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


13 September 2009