Share via

FIT, DSLs, and test engines

  • Article

Peter has a few thoughts about Ward Cunningham's FIT (Framework for Integrated Tests).  He encapsulates the ideas behind FIT very well.  This post (and some of the challenges I had getting FIT to work in a complex problem domain) raises a few ideas, thoughts, questions, and things to ponder. 

  • Can you have an engine for creating domain specific languages (DSLs) that allows it to be used by just about anyone to create a simple, easy to understand DSL for just about any software problem?
  • What is lacking from current test engines that would help the industry get to a place where customers (business folks, end users, etc) can write executable tests for a complex problem domain, simply using their own tool of choice?
  • Is all of this just a pie-in-the-sky dream that can and will never happen?

This is something that has been nibbling away at the back of my mind for a while.  And I think it'll continue to work away for a while before I and we as an industry can come up with a good answer.

[Edit: categorized this post into a new category: Testing.]

Comments

  • Anonymous
    July 27, 2006
    This is something we tried to attack with Avignon (avignon.sourceforge.net) but the XML has proven to be a turnoff for some folks.

    The original idea was that customers could script a test using a limited vocabulary of their own creation and then developers could implement that vocabulary with handlers. FIT turned out a lot alike in that regard (and something I like about the original FIT was the idea of creating the test document in something like Word and then making it executable).

    We had some success in Avignon by being able to implement "handlers" with more XML scripts, a nesting effect. So that:

    <FillForm name="Joseph" age="30" hobby="Programming"/>

    could be implemented with
    <ScriptBlock>
      <EnterText name="nameField" value="#name#"/>
      <EnterText name="ageField" value="#age#"/>
      <EnterText name="hobbyField" value="#hobby#"/>
    </ScriptBlock>

    Where EnterText is a pre-existing handler. This is still possible in a tool like Watir, but the original test needs to be written in Ruby anyway, and the implementations of all behaviors would be in Ruby as well.

    I'm not sure what would be the next great step - it reminds me of those old text adventure games with their "domain specific languages" of verb/noun sentences. How easily can one grow a bigger language?