From: Phlip <phlip_cpp@...>
Date: 2005-03-25T06:14:49+09:00
Subject: Functional tests

[x-post from the TDD mailing list, because I kept writing Ruby in it...]

Robert Hanson wrote:
>
> Can someone point me to a resource for Functional Tests?

http://fitnesse.org

FTs are an alternate GUI skin for your application. They don't fit your
user's usability profile. They fit your Onsite Customer's usability profile.

> And how they are
> implimented differently than TDD tests.

TDD tests (and formal test-last tests) make them easier. For example, I
might write a special test case in the TDD rig which takes a command line
argument. Then when I call the rig from a command line

Then I write a test runner, using a dirt-simple language like Ruby and a
dirt-simple GUI like HTML. This will

http://flea.sourceforge.net/gameTestServer.pdf

Scroll down to the end of that and read backwards.

> Does the customer create the
> tests, or does the XP team?  Do you use the same XUnit framework for these
> tests?

Attend to the Onsite Customer's usability profile. Even if your Customer can
program, you shouldn't make them do it.

Many TDD test cases are lists of inputs and expected outputs. The first part
of growing an Acceptance Test Framework is to escalate those lists into
tables in a _light_ database format, such as XML or YAML.

Here's one of the FITnesse samples,
http://fitnesse.org/FitNesse.SuiteAcceptanceTests.SuiteWidgetTests.TestHeadersAndFooters
, converted to (presumably) YAML:

fixture: Page creator.
table: [ [ Page name, Page contents, Page attributes, valid? ],
           [ NormalPage, normal, ,   true ],
           [ PageHeader, header, ,   true ],
           [ PageFooter, footer, ,   true ],
          ]

(That looks better with ASCII formatting an a monospaced font.)

The goal is to make those tables easy to write, and literate. The other goal
is to make them easy to program, and link to your application.

Now take my Wiki, MiniRubyWiki, and use the feature described here:

    http://www.c2.com/cgi/wiki?BroadbandFeedback

My Wiki can transform simple XML into the XHTML <form> to edit its
attributes. An XML node's content area turns into a big text edit area.

When you click Test, the Wiki saves the XML into its file, and calls a test
fixture with it on the command line. So if you write a fixture called
fixture.rb, it sees this command line:

    ruby fixture.rb myTestData.xml /suite/case[2]

The /suite/case[2] part is the XPath to the case that you clicked Test on.

Now imagine if you wrote a YAML table into the <textarea>. It would go into
/suite/case[2]/text(). Your fixture.rb will read this string, interpret the
YAML, get a list of lists out of it, and execute each item in the list as a
command. Each command tests your application (possibly using a hot-wired TDD
test case), and writes the result back into the YAML. Then MRW refreshes its
fields to reflect the test status.

These systems allow you to author test cases (and clone them all over the
place) using a convenient and very-high-level interface. You get there by
using an extensible GUI, such as a Wiki, or Excel, or Word, and you write a
bunch of low-level code that bonds generic fixtures with specific data to
your testee modules.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces