Re: [Oorexx-devel] Some ooRexxUnit questions.

[Rony G. F. <Ron...@wu...>]

Rick McGuire wrote:
> The enhancements I've been working on for date() and time() are
> turning into a fairly major code refactoring operation.  Having a good
> regression suite would be helpful.  I don't really see any
> time()/date() tests in our current test bucket.  Do we have any tests
> for these functions written?
As Mark mentioned, the only ones that exist so far are the examples from
the documentation (used to check back then that the documentation's code
snippets are correct), which are stored in
"tests/oorexx/ooRexx/base/ooRexx.Base.BIF.testUnit".

> Also, I'll probably write some tests of my own, and would like to add
> the tests in ooRexxUnit format.  Because there are so many options to
> test, I was sort of planning on writing a test generator program that
> I can feed a series of "edge" dates and time that are likely to cause
> problems.  The generator will run on a previous release, and for every
> input, will run through an exhaustive set of format conversions and
> write the results to a control file. 
>
> Then, to run the tests, I'd like to read the control file and redo the
> conversions and verify the results of each operation.  Do we have a
> convention for where extra resource file like these results need to be
> placed so they can be located by the test runner?
No there is no convention as of yet, so we are free to come up with
anything that makes sense.

At the moment there are two conventions in place w.r.t. naming of the
testunit files and of creating temporary files that are needed for the
tests:

- ad naming: the convention of naming at the moment is as follows: the
name is a dotted name where each directory becomes part of the file name
and finally leading to the name which describes the general purpose of
the testunit. [Originally (while being developed) the testUnits resided
in one directory and this naming convention allowed for classifying the
testunit. Later, the testUnits were moved into a directory structure
matching the classification.]

- ad temporary files needed for testunits: this follows the junit specs.
If a test case needs some sort of a temporary setup that setup
(environment settings, files, etc.) should be coded in the method
"setup". The code to remove all those temporary changes should go into a
method named "tearDown". For each test case (method that starts with the
string "test") first the message "setup" is sent, then the test case is
executed and then "tearDown" is sent. This way each test case has a
defined environment to start and cleans up afterwards.

---

Ad the "special case" that fixed configuration/input files are needed, I
would propose the following convention:

- name all those files like the testUnit file that needs them, but use
different filetypes instead of "testUnit", e.g. for ta test unit named
"ooRexx.Base.aSpecialTest_01.testUnit", a needed configuration file may
be named "ooRexx.Base.aSpecialTest_01.config", an output file
"ooRexx.Base.aSpecialTest_01.output". You would place the necessary
setup code in the method "setup", have one testcase running all the
tests on those input files, producing the output file, and place all
clean-up code in the method "tearDown".

Keeping all files together in the same directory would allow to use
"PARSE SOURCE" from the testUnit to identify the location where the
auxiliary files are located. [Having a special directory for placing
auxiliary files would disperse the files that together constitute the
testUnit.]

HTH,

---rony

P.S.: There is even a reference card for ooRexxUnit:
<http://wi.wu-wien.ac.at/rgf/rexx/misc/refCard/ooRexxUnit.pdf>.
[Actually, the Assert class should be a mixin class and inherited by the
TestCase class, which might be more understandable. This way it matches
the junit structure.]