I worked on and off again for about 2 years on a new OSS project called StoryTeller. My original goal was to create a better editing and test management tool for Fit tests than the FitNesse Wiki approach. I had *some* success, and I was able to use the rough StoryTeller UI on a couple projects. Even in its rough form, I think StoryTeller was already better than FitNesse (as long as you knew what things on the UI that were not ready to be clicked on;) All the same though, I haven’t found the tool to be all that successful, and my enthusiasm for the project has waned. All of this is just an explanation for me announcing that I’m abandoning the original StoryTeller approach altogether.
For those of you who have asked me where the old code went, I’ve shelved the old code in a new SVN branch at: http://storyteller.tigris.org/svn/storyteller/branches/old (for anonymous access, the user id is “guest” and the password is blank).
I still believe in Fit from a conceptual standpoint, but I’ve simply had it with the Fit mechanics. Last week I started StoryTeller over from scratch, but this time I’m ditching Fit altogether and building a new test automation engine from scratch. I don’t have a lot of information on it at the moment, but I’m hopeful that I’ll be able to demonstrate the new StoryTeller in action as soon as KaizenConf in three weeks.
- StoryTeller is being conceived as a dedicated tool for crafting external testing DSL’s, and a UI for editing that DSL. The test editing will be done mostly in forms rather than in text. The point is to make test editing as guided as possible to make editing more efficient and less error prone.
- I’m building a brand new testing engine from the ground up. I think the new engine will make it easier for .Net developers to write the Fixture code and make it much easier to expose the metadata that the UI will need to create the test visualizations and test editors
- I’m pitching StoryTeller as an automated testing tool that creates human readable specifications rather than a tool to automate specifications. It’s a subtle shift in focus, but my experience has been that analysts and business partners either can’t or won’t participate in Fit test writing. Hell, getting business people to even look at Fit tests has been a trial. StoryTeller New is being built to be as easy to use as possible for reasonably able developers. Specifically, it’s getting built for my team and my project with the hope that it will be useful for somebody else too.
- The UI will be built from the ground up in WPF. I’m hoping to use the UI for sample code in my book on UI patterns. I think WPF is miles ahead of WinForms in its ability to do dynamic layout, and I’m going to push that ability as far as it will go.
Why I’m abandoning the FitnesseDotNet engine
I feel like I owe a bit of an explanation for this decision. You can find most of the reasoning at Why I’m Suddenly Down on Fit/FitNesse. The final nail in the coffin for me was way too many conversations like the following:
“Well first, make this a ColumnFixture and override the Execute() and Reset() methods. Then override the DoRows() method, but be sure to call base.DoRows() before you add your code. Then write a DoFixture class with a method that returns your new ColumnFixture”
Blech. I love the concept behind Fit, but the implementation leaves something to be desired. It’s just plain weird, and far too laborious to craft Fixture classes. We partially beat the issue by doing quite a bit of code generation, but I’m in the camp that says code generation is a border line code smell. In bullet point form, here’s why I think it’s time to move beyond Fit:
- Test writing with Fit is very failure prone. Fit is very sensitive to formatting errors and there isn’t a good way to discover syntax errors without running the tests.
- The test management tools for Fit suck
- The extensibility mechanisms (ICellHandler etc.) are odd and hard to understand, but understand them you must
- It simply takes far too much knowledge about how the Fit engine works to write Fixture classes. Very few people are willing to make that investment.
- The FitnesseDotNet engine has become far too coupled to FitNesse. The last time I pulled a new build, I had to fork the code to get it to run outside of the FitNesse Wiki engine.
There’s a lot of things shaking out there in the world of test automation. I’m not sure that I’d say that StoryTeller will be a direct competitor to the xBehave and xSpec tools. ThoughtWorks just released Twist, and it looks roughly like what I’m envisioning, but the TW clowns made it Java only and tied it to Eclipse (and I detest Eclipse). Bob Martin just announced a similar sounding tool called “Slim” as an alternative to the Fit engine for FitNesse, but it doesn’t seem to address the issues I have with Fit and FitNesse. There’s also a chance that the textual DSL tooling in Oslo could do what I want StoryTeller to do. I’ll keep an eye on all of these just in case.