I owe some folks a couple blog posts, but I had to get this puppy out of the way. This white whale is swimming free, but I’ve got StoryTeller in my harpoon sights.
I announced StoryTeller nearly a year ago and its finally getting close to a real release. The tagline is simply this: “StoryTeller is the FitNesse killer for .Net.” My express goal is to fulfil the promise of FitNesse with less frustration and friction. This isn’t really about criticism of FitNesse so much as just trying to make the next step. This tool would not exist without the inspiration or FitNesse.
I have absolutely zero intention at this moment at making StoryTeller run Fit tests in anything other than .Net. StoryTeller is intended to provide the best possible experience for .Net development without compromising for cross language support. Besides, there are other tools for Java and other languages.
From the original announcement:
StoryTeller is a new tool for efficient creation and management of automated testing of .Net code with the NFit/FitNesse engine. StoryTeller is specifically created to support an Acceptance Test Driven Development strategy. All existing .Net FitNesse tests will run under StoryTeller. Features will include editing, tagging, and integration with source control, CruiseControl.Net, NAnt and/or MSBuild, and support for application versioning.
It’s taken a long time, and it’s not really done yet, but I finally feel like I’ve got enough here to warrant a real release. The UI client is still rough, but it does work. I’m thrilled with the response to a call for beta testers, so here it is:
And I did the amateurish thing by creating the package by copying all the files in bin/debug which inevitably misses GAC’ed assemblies. So also go download the telerik assemblies at http://storyteller.tigris.org/svn/storyteller/trunk/tools/telerik. I’ll get the zip repackaged tonight.
Download the zip file, unzip, and double click on the executable and you should be good to go.
Things to Know
- StoryTeller is aimed very squarely as a replacement for FitNesse on .Net projects. It still uses the same test engine.
- StoryTeller stores the test files as either HTML or Wiki text. Some options aren’t supported with the Wiki text. One of my goals was to make the tests easy to edit by hand or your html tool of choice.
- You edit the tests inside the StoryTeller GUI with a subset of the FitNesse Wiki format. See the FitNesse website for more details.
- SetUp & TearDown works a little differently than FitNesse. You can optionally define a SetUp and/or TearDown for any Suite. When a test executes, StoryTeller will execute the SetUp, if one is found, for each anscestor Suite. For example, a test with the path “Suite1.Suite2.Suite3.Test1″ will first run “Suite1.SetUp” then “Suite1.Suite2.SetUp” then “Suite1.Suite2.Suite3.SetUp” before executing the actual test. TearDown’s work similarly, but in reverse order. The TearDown’s are executed by the inner most parent in this order: “GrandParent.Parent.TearDown” then “GrandParent.TearDown” and so on.
Starting a New Project
The first thing to do is to configure a new StoryTeller project. Inevitably, it’s an Xml file. There is a form in the client to configure the Xml file, but for the sake of documentation I’m going to describe the Xml file (it’s just a serialized object by the way). The sample project file looks like this:
<Project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- List of all possible tags for the project-->
The only valid Project type is "Local" for the moment. I had a "FitNesse" project at one time and plans for a "Remote" project.
All it means is that the tests are run locally
The directory containing the assemblies and configuration files for the SystemUnderTest. The StoryTeller.dll must also be in this folder
The path can be either absolute or relative to the project file
Optional, but recommended. As assembly qualified name of a class that implements the StoryTeller.IFixtureLibrary interface.
The role of the IFixtureLibrary interface is simply to register Fixture type's with the Fit engine.
The folder that contains the StoryTeller tests. The root Suite's will each be a directory under this folder.
The path can be either absolute or relative to the project file
<!-- The displayed name of the SystemUnderTest -->
<!-- Controls the format that the StoryTeller engine uses to persist tests. At this time I *strongly* suggest the HTML option-->
<!-- Set a timeout on test execution. Any number <= 0 will be treated as infinity. The TimeOut is somewhat problematic at the moment-->
Purely desperation. If you need a completely clean AppDomain for each and every test run, choose this option.
Needless to say, this will slow down the execution time to a painful crawl. And yes, I had to have this in a previous
Running from the Command Line
There is a command line runner called StoryTellerRunner.exe in the download for running StoryTeller tests from a command line. This is the tool for integration with build scripts. I originally intended to do this with NAnt tasks, but decided on the command line approach for maximum reach. The command line is:
StoryTellerRunner.exe ProjectFile OutputFile \n [-description:AAA]\n [-suite:AAA]\n [-tag:value] (can be repeated)
- ProjectFile is the path to the StoryTeller project file
- OutputFile is where you want the TestReport to be saved
- -description:Text is simply a way to add a description to the TestReport
- -suite:Suite Path is the path to the Suite you want to run. Use this to limit the test run to only this Suite
- -tag:value – run tests with this tag
- -status:Acceptance or -status:Regression – Only run tests in this state. Conceptually, you could make one test run that executes all the Acceptance tests but doesn’t fail the build, and a second regression test run that will fail the build on any test failures.
It’s not complete, and I’m hoping to do one more beta before 1.0. I’m releasing this now to get feedback. From the response I’ve gotten, there’s an obvious demand for something like StoryTeller. The stuff that I’ve definitely got left is:
- Syntax checking – Simply highlight test rows that don’t match up with the Fixture classes
- A Fixture explorer in the UI tool
- Exporting reports and results from the client
- Reloading a project
- Canceling tests in the execution queue
- Creating playlists on the flow
- Adding the component versions to the test reports
- Making the UI not be butt ugly
- Docs, lots of docs