After four years of off and on work, one complete reboot, and over 18 months of hard usage in anger at Dovetail, I’m finally calling StoryTeller 1.0 today and kicking out an official release on GitHub. I can’t say that it’s perfect, or the docs are complete, or there aren’t some big features still missing that I wish were there, but I’ve got some early adopters chomping on the bit to run it through its paces and nothing improves an OSS project like actually having it used and getting feedback from folks in different projects.
Unfortunately for you the early adopter (but awesome for me), I’m on vacation and I’ll be very slow to respond this week (believe it or not, there are places in the continental US without the internet, like my grandparents’ farm;-) ). All the same, I really needed to get this into the hands of another team in Vancouver today, so here you go. I’ll be blasting CodeBetter with StoryTeller examples and content starting next week. Check back then…
Fork the Source Code and Look at Examples Here. – Strongly recommended if you’re going to try StoryTeller seriously
Follow StoryTeller on TeamCity (and watch Jeremy fumble with Git) Here.
Here are the salient facts:
- StoryTeller is a tool for creating and using “Executable Specifications” against .Net systems. StoryTeller could be called a Behavior Driven Development tool depending on which of the billion definitions of BDD you subscribe to, but is very much optimized for customer facing tests. I meant StoryTeller for the older ideas of Acceptance Test Driven Development that predate BDD.
- StoryTeller will also be usable as an External DSL engine that can be embedded in your web applications – but that’s another story altogether
- StoryTeller is released under the permissive Apache 2.0 license – meaning that anything goes with the source code
- StoryTeller is heavily inspired by the earlier Fit and FitNesse tools. While I’ve always liked the intent of FitNesse, StoryTeller is largely born out of my frustrations with FitNesse’s mechanics
- Unlike Cucumber (what I’d call its most natural competitor), StoryTeller fixtures and grammars are written completely in .Net and “projected” into a display (and the editor) instead of parsing text. I’m not saying that I think StoryTeller is better than Cucumber (only you can decide that), but it does take a very different approach towards the same goals.
- I would never, ever say that StoryTeller is a replacement for xUnit tools or finer grained specification tools like Machine Spec. There is some overlap, but I can easily foresee teams using both something like Machine Spec and StoryTeller on the same project.
- Right now, StoryTeller is very developer centric in its workflow, but I’m hoping to change that going forward with tools to allow non-developers to design an empty shell of the specification DSL without developer intervention
- I hope to have the documentation complete by early next week (it’s July 5th, 2010 as I write this)
- I’ll be blasting CodeBetter with StoryTeller examples for the rest of July 2010
Yes, I do realize that the TeamCity build is broken, but my window of opportunity this morning is closing and I’m not fighting with Git on my vacation;-)