Re: R: RPG Indicators

[Anton Gombkötö <Gombkoetoe@xxxxxxxxxx>]

Barbara,

thank you very much for lifting the curtain a bit for us (again)! I really
love these insights!

And you are completely right with your suggestions. I think that everybody
changes a value in the debugger now and then to save another compilation and
setting up the test environment again. This shouldn't become a general
manner.

Test cases are nice, and often quite easy to create for batch jobs, that's
why it's sometimes done. For interactive jobs, or better: for programs with
a display file, this isn't that easy and that's why it's seldom done, at
least i do not know of programs being capable to check themselves. The job
is easier now as procedures/functions came and these are easier testable and
do not interfere with each other as subroutines can. On the other hand,
dividing up "old" (or future) programs into the user interface and the
processing part is becoming a common task as one wants to be able to have
other interfaces (e.g. web), which makes testing easier as the processing
part is now a batch program.

Anybody out there with a recommendable method to create testcases,
expecially for programs doing screen I/O?

Thanks again,

--
Anton Gombkötö


-----Ursprüngliche Nachricht-----
Von: <bmorris@ca.ibm.com>
An: <RPG400-L@midrange.com>
Gesendet: Donnerstag, 20. April 2000 16:11
Betreff: Re: R: RPG Indicators





>Date: Wed, 19 Apr 2000 23:12:52 +0200
>From: Anton_Gombkötö <Gombkoetoe@ASsoft.com>
>
>>From: Jon Paris
>>I believe Hans commented previously that they were looking at ways of
>>making the BIFS "debuggable" in the future.
>
>Maybe there's an "internal" field like for the null indicator that can be
>debugged?
> ...
> Is there? If not, such fields would do!

Sorry, but I don't think there will ever be debuggable values for
the bifs.  Some of the bifs do have associated internal fields
(currently, but maybe not in the future if we find some case that
can only be determined by generated code) and some require generated
code to determine the value.  Even within the same bif, some files
require generated code for the bif and some can use an internal field.

For the bifs that require generated code, a debugger value would only
be reliable after the statement containing that bif had been executed,
and then only if that particular bif had been evaluated.

For example:

1 c            read(e)   file
2 c            if        %error or %eof(file)
3 c            do something
4 c            endif
5 c            do something else

If %error is on, %eof would not be evaluated, so a debugger value for
%eof would be unreliable.

I would never support changing the rules for short-circuit evaluation
under debug, since that would cause other debug-only changes that might
make a program run differently (e.g. if a procedure call was involved in a
conditional statement and the call was made only during debug because
the truth-value of the statement could be determined without the call).

I know how nice debuggable bifs would be.  While I was unit-testing
this enhancement, I sometimes had to temporarily change my test cases,
adding code to save the value of a bif.  If it had been possible to
add debuggable versions of the bifs, I would have done it.

A final personal opinion: using the debugger is good for finding
problems, but the debugger shouldn't should be used as a quick and easy
method for testing.  Permanent self-checking testcases should be created.
The time taken to create testcases is never wasted - if you write a
testcase that specifically tests a section of code and some maintenance
programmer (maybe you) comes along later and messes it up, the test
case will find it immediately.

I guess that wasn't quite my final opinion.  Here's another one: there's
nothing wrong with writing your code so it's easy to debug.  That usually
makes it easy to read (and test) too.  If you really need to know in the
debugger whether it was %error or %eof that took you into a section of
code, then maybe your code would be better with two separate if's.

Barbara Morris


+---
| 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
+---