Re: Agile methods

[Buck <kc2hiz@xxxxxxxxx>]

Terry wrote:

> This seems eerily similar to test "scripts" that I have seen 
> used in the past. These so-called scripts were nothing but 
> step-by-step documents outlining a test method and employed 
> by the user community to ensure that their new application
> worked correctly. 

The difference is that Agile tests are automated.  Here's an example of 
a RPGUnit tests.  Even without seeing the contents of formatSocSec, it's 
pretty easy to see what the intent of these tests.

// No formatting
inputSoc       = '111223333';
expectedResult = '111223333';
assert(formatSocSec(inputSoc: 'N': 'N') = expectedResult:
  'no formatting pass');

// No formatting
inputSoc       = '111223333';
expectedResult = '111-22-3333';
assert(formatSocSec(inputSoc: 'N': 'N') <> expectedResult:
  'no formatting fail');

// Default formatting
inputSoc       = '111223333';
expectedResult = '***-**-3333';
assert(formatSocSec(inputSoc: '': '') = expectedResult:
  'default formatting');

Apologies for the RPG.  These lines go into a source member, one set for 
each test I want to perform.  Then I run RUCRTTST to build the test 
harness and RUCALLTST to execute them all.  The test framework binds to 
the service program holding the subprocedure, so it always runs the 
production code.  If an 'assert' fails, it issues the message shown.

The tests themselves compare the actual results against expected 
results.  This works great for calculation-heavy functions, but requires 
some serious discipline in a database-heavy application.  Today, our 
'crummyCust' customer ID might point to a record that has too much A/R, 
but tomorrow, someone might use that customer to work on a 'write down 
bad A/R' function!  Another gotcha is learning to write small functions 
that are individually easy to test.

No silver bullet, but it's better than randomly hoping for the best :-)
  --buck