Ward Cunningham and Brian Ingerson are giving this talk. The focus in on
extreme programming (XP) which requires continual testing. We start with an
example from Ward Cunningham of financial interest calculations, which are based on the
assumption that each month has 30 days, and each year has 360 days. So he
defined tests with a list of sample cases and expected results, and uses a
tool to run the tests for that list. Fill in the table, then send the table
to the testing tool, and get a table back with what should have happened,
versus what did happen. When the tests were all passed, he added another
test (another row), which failed. He fixed his code: now the new text
worked, but the old ones were broken. This is a simple way to make sure
that you don’t lose what you used to have when you fix or extend code.
By the way, the wireless network is broken again. There’s good Wi-Fi
connectivity, but there’s no working DHCP server. I can’t understand why
they are having so much trouble with this! The last several years had great
wireless networks at the conference. (Later: DHCP is back, but there’s no
routing beyond the gateway.)
This talk is available on-line.
Now we’re moving on to Brian Ingerson, who’s moving away from Java to
open source languages (especially Perl). He’s written Test::FIT for this,
and used it in CGI::Kwiki and YAML.pm. Again, the FIT tests are tables,
which seem pretty easy to write, and the tool is a web program that reads
the table, runs the tests, and writes a new table with columns showing the
results. Ingy runs a kwiki in every module directory, and includes FIT
tests. There’s an example
online. This isn’t the
standard Perl way to write tests, but he has a tool to create standard t/
tests from the FIT cases, so “make test” runs the same tests.
To get this everywhere, he and a friend wrote Module::Install which will
let you install modules on all platforms (for example, it will get nmake.exe
for Windows users if they don’t already have it). Also check out the FIT
Kwiki’s at Kwiki.org and
Freepan.org (which is a CPAN like
structure for all open source languages, not just Perl).
How about providing the same modules for all open source languages? FIT
could be the specification platform, and as soon as someone wrote a
candidate module for a particular language, if it passed the test it would
be made available.
Charles Engelke's Blog 