Cucumber is an acceptance testing framework that lets you and your clients write our requirements as short stories and then test those stories fro compliance. Those familiar with it will know that you can tag a scenario by placing putting labels precede by the @ sign on the line imminently before the scenario starts. There are a number of different uses for these tags. They can sort features by priority or developer, or they can designate in what version the feature is likely to appear.

As a one-man-band, I don't need quite that level of organization. But I do use three tags that help me keep my development clean. I do however label all my scenarios as @pending, @current or @passing. I can then use the -t flag to choose which tags to run.

Initially all new scenarios start out as @pending (whether that is the result of running them or not).

Once I pick a story to work on I change the tag to @current. Cucumber features usually test the full stack, and some of mine will soon have to test in-browser unless someone can find a good headless browser that can run jQuery. In other words, they are slow, and I don't want to run the frequently. Instead I write my usual unit spec's and only run the feature when I think I've got something working. The @current tag make it easy to look just at the scenario I'm working on without having to track it down sometimes more then a day after I started working on it.

Finally, @passing denotes all the features that I think are implemented correctly. I run this set before I deploy to ensure that everything I thought was working still is. I have found that it helps to catch configuration and deployment errors that my spec's are just to fine grained to catch.

Even using a very small and basic set of tags has helped me to keep my features organized, prevent pending features from becoming "broken windows," and kept cucumber as a useful tool for both development and testing.