Re: Agile methods

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