Refactoring: Adding cmd line runner to parse user-written BDD Stories into stubbed mspec code

[eduncan911]

E.g. spec, mspec, bdd, etc.

A conversation I had with a user recently gave me an idea. I have always asked the user to write general BDD-style ticket and bug reports. For example:

Story: Registering a new user
  As an user visiting the site
  I want to signup
  So that I can use the system

Scenario 1: User is unregistered
Given the user is not signed in
  and their email address does not exist in our system
  and their username does not exists in our system
  and they do not uncheck Subscribe to our Newsletter
 When the User registers
 Then a new User is created
  and a welcome email is sent to the User
  and a verify email address email is sent to the User
  and they are subscribed to our newsletter

While usually not that pretty, I have gotten 100s of tickets and bugs like this in the past.

So, I had a thought:

why not take this, verbatim, copy-n-paste it into a text file, and execute a command line parser that generates the actual mspec code that is all stubbed out?

Makes total sense. Using go generate, just parsing raw text and generating all the Given, When and Thens that are needed. The entire workflow (from scratch) would be:

go install -v github.com/eduncan911/mspec/cmd
cd $GOPATH/src/company/www/
mspec jim-user-story.txt > registration_test.go
go test

It is boilerplate code that I have typed 100s of times by hand. This utility will generate and output the complete file, ready to go test and will output the NOT IMPLEMENTED we all love about the Stubbing feature of mspec. Lovely!

GoConvey actually follows this paradigm as well with their browser. But the focus of this utility will be lightweight copy-n-pasting and parsing. Oh, that's another idea: reading from the Clipboard of the OS directly.

mspec -from clipboard > registration_test.go

Of course it isn't a replacement for double-loop unit and bdd testing that you should continue doing. But, it gets the Acceptance Testing coded out for the developer, leaving them free to iterate with normal TDD quickly.

See #4 and #9 for more details.