In my previous post, I wrote how I’ve recently been getting to grips with Cucumber and Pickle. To do this, rather than trying to retro-fit Cucumber stories into another app, I decided to start with a fresh new Rails app: Molehill.

Molehill is an experiment, both in learning behaviour driven design (BDD), and also trying out some ideas for a simplified issue tracker.

Molehill is open-source, and can be downloaded from github. See the end of this post for more details.

Post. Fix. Close.

Molehill is designed to avoid the problem I’ve found with other issue trackers I’ve used – they do too much. They require so much overhead setting up and managing versions, milestones, time estimates, shipping forecasts, gantt charts, and so on – that it’s as much work posting a case as actually fixing it.

Molehill takes a much simpler approach, purposefully avoiding all that which makes other issue trackers so heavy. Instead, Molehill is based on the idea that tracking bugs and features should be as simple as post, fix, close.

Posting and Promoting Cases

Taking cues from Twitter and the micro-blog format, cases are written as simple posts which are dropped into a timeline.

If a case is posted that you think is important, you can promote it. The more promotions a case has, the higher it appears in the timeline.

For developers, this means that your users’ most desired bugfixes or features are always sitting at the top of the timeline. Instead of spending hours building roadmaps, and scheduling cases for release in 6 weeks (if you’re lucky), just work on whatever case is next at the top of the list and release it.

Closing Cases

Once a case has been fixed or implemented, the original author can mark it as such; or – if it’s not going to be implemented – it can be marked declined.

At the moment, only the original author can close a cace – I’ve intentionally avoided roles (such as Developers and Reporter) in Molehill, although I may have to make an exception so that developer’s can mark any case as completed or declined.

An alternative approach might be to allow any other use to suggest a case is complete, or indicate that it won’t be implemented. This might be better achieved through a reply system though, like Twitter’s @reply tag.

Categories and Projects

Molehill doesn’t have a concept of projects, but does allow #hashtags within a case. This means cases can easily be tagged and categorised to a project or feature, for example:

There should be a way for #molehill to categorise or tag #cases.

A quick search from the homepage, or click on the #hashtag, reveals any other cases tagged with the same words.

Cucumbers Everywhere

I built Molehill primarily to learn Cucumber, and doing so has got me hooked on writing feature-first code. The majority of Molehill was built without once launching Firefox or Chrome; everything was instead written as a feature, and run through Cucumber and Webrat until that feature passed.

Good Cucumber coverage allows far more confidence when deploying your code that everything works together. Too often I’ve seen a minor fix in one part of an app have a completely unforeseen effect on some screen assumed to be unrelated. With Cucumber, and a good test suite, these worries can be all but forgotten. Now that it’s in public beta, I’m working to retrospectively cover Amberleaf in Cucumber stories

Getting Molehill

Molehill is open sourced under the MIT licence (the same as Rails). You can grab a copy of the code from github, and setup your own local Molehill server using the following steps:

$ git clone git://github.com/cblunt/molehill.git
$ cd molehill
 
$ cp config/database.yml.sample config/database.yml
# You'll need to configure your local database in config/database.yml
 
# Molehill has a number of gem dependencies, including Cucumber and Pickle
$ rake gems:install
 
$ rake db:migrate
$ rake db:migrate RAILS_ENV=cucumber
 
$ rake cucumber

You can also generate an RCov coverage report (saved in features_coverage) using:

$ rake cucumber:rcov

There is a live demo of Molehill running at http://molehill.chrisblunt.com. To begin with, I’ll use Molehill to track its own development. However, if it proves to be a workable concept (and requires less management than a full redmine setup), I’ll probably use it for Amberleaf’s issue tracking as well.