RE: Agile methods

Buck,

This is a very interesting technique, thanks for sharing!
Obviously, this method requires key considerations be
given to the design of the system. IMO, it would have to
be carefully architected to support small and very simple
modules to permnit this low-level type of testing.

Sheesh...I'll never see this type of environment...lol
As Luis so eloquently stated in another reply:

"Everybody wants to replace those programs that are badly
designed, but we know it's almost impossible."

Terry

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck
Sent: Tuesday, January 29, 2008 2:26 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
--

Confidentiality Notice:

The preceding e-mail message (including any attachments) contains information that may be confidential, protected by applicable legal privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution or reproduction of this message by unintended recipients is
not authorized and may be unlawful.