Seeing as FIT has a Perl fixture, why not just use FIT?

That'd be the FIT port that I did, which was complete in early days, and served to shake out some issues in FIT early on, but hasn't been touched since, largely due to lack of interest on the part of anyone in the Perl community at the time. (I prefer to work on stuff that gets used. There weren't takers then; there might be now.)

I'd rate my port as being better than "proof of concept", and probably good enough to base work on if you're willing to roll up your sleeves, but it's not anywhere near current.

Ingy did another port, (the one on CPAN), shortly thereafter. I don't know if he's kept his updated, either.

There's been some backchannel discussion about getting the Perl port updated for FIT 1.1. If anyone is seriously interested (say, in helping out), /msg me.

/me slaps forehead and hides in shame

Thanks!

pernod
--
Mischief. Mayhem. Soap.

Fitnesse is a wiki built atop Fit, which creates test cases from HTML input. The wiki interface allows non-technical users to edit these input/output tables, and by interspersing these tables with a descriptive story (in XP/agile parlance) you get an executable requirements specification. Written by the user. Sounds like Utopia.

While FIT does indeed rock (especially with FitLibrary) it's not the only solution to getting requirement specs written by the user.

A technique I use a fair bit is to create a domain specific language for the user to write there tests in. Usually in Perl or Ruby. So instead of the FIT document shown here the user might write:

do_chat {
  connect_user "sarah";
  user "sarah" creates_room "fit";
  user "sarah" enters_room "fit";
  users_in_room "fit" name_is "sarah";
};
[download]

Never realising they're writing Perl :-)

Another common solution I've used is to get the user writing their test input/output in an Excel spreadsheet and parse that. Again, you get the user to use the tools they're more familiar with.