Re: R: RPG Indicators

You could use one of the windoz testing tools if you are using a windows
based terminal emulator. Or you could use DDE to control the terminal
yourself and send the appropriate keystrokes etc to the program. That is
where I would start to look if I were you.

Eric

______________________________________________
Eric N. Wilson
President
Doulos Software & Computer Services
2913 N Alder St.
Tacoma WA 98407


----- Original Message -----
From: "Anton Gombkötö" <Gombkoetoe@ASsoft.com>
To: <RPG400-L@midrange.com>
Sent: Friday, April 21, 2000 1:40 AM
Subject: Re: R: RPG Indicators


> Thanks!
>
> Well, as i tried to express, writing a testcase for "batch" functions
isn't
> too hard, but what about the display programs? Is there a method for
testing
> them automatically? I can think of a "record" mode in which entries are
> stored somewhere and a "test" mode where screen input comes from a dtaq.
> Then the results of the recorded run have to be somehow compared to the
test
> run and differences logged.
>
> I'm now mainly interested in such a thing and so i keep on asking for
> experiences and/or tricks on this sector.
> --
> Anton Gombkötö
>
> -----Ursprüngliche Nachricht-----
> Von: "Chris Bipes" <rpg@cross-check.com>
> An: <RPG400-L@midrange.com>
> Gesendet: Donnerstag, 20. April 2000 19:29
> Betreff: RE: R: RPG Indicators
>
>
> <snip>
> Anton Gombkötö
> Anybody out there with a recommendable method to create test cases,
> especially for programs doing screen I/O?
> </snip> =-0 to much html
>
> We in general for debugging save the passed data to the server in a file.
> We can turn on or off this capture flag with an external data area.  This
> allows us to write a small program for testing to re-send a days worth of
> trapped data to the server and check the responses.  We can also save live
> working data today to use as test data tomorrow when we are enhancing the
> functions of the server program.  This is a direction we are moving, not
> there yet.
>
> If you have a program that you are going to break into Client/Server,
first
> make all the edits of the screen and business logic a callable module.
You
> can then separate the screen I/O from the business logic and save the
parms
> passed to the edit modules in a file.  Now write the server to receive the
> edit parms and call the edit module.  Just remember that any work
variables
> used in calc can not be retained from call to call in a server
environment.
>
> Good luck and I hope this helps with your design.
>
>
> Christopher K. Bipes mailto:ChrisB@Cross-Check.com
> Sr. Programmer/Analyst mailto:Chris_Bipes@Yahoo.com
> CrossCheck, Inc. http://www.cross-check.com
> 6119 State Farm Drive Phone: 707 586-0551 x 1102
> Rohnert Park CA  94928 Fax: 707 586-1884
>
> If consistency is the hobgoblin of little minds, only geniuses work here.
> Karen Herbelin - Readers Digest 3/2000
> Thanks again,
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---