All,

I just committed to the test suit the implementation of some features
that were planned from the start, but never gotten to.  Plus the
implementation of a feature Rick asked for a little while ago.

I've tested the changes pretty well, but I'm sure there are some
hidden bugs.  The main, most general use should be solid, any bugs
should be in some obscure interaction of the options.  Like, what
happens if you include all test types and exclude all test types, and
then also use the -a all test types option.  (Which I did test and
works.)

Let me know if you hit a bug so I can fix it right away.

The 2 main additions are the use of an options file and the ability to
only execute a single test case from a test group.

* Use of an options file to specify options.

When the test executor starts it will look for an options file.  If
found it will read the file to set any options.  The hierarchy of
options is as you would expect.  The known options all have a default
value.  Options set in the options file over-ride the default.
Options set on the command line over-ride the options file.

The default options file name is: options.ooTest

There are two new command line options:  -o and -O  With -o you can
specify the name of the options file to use.  -O says ignore the
options file if it exists.

The file is read as a .Properties file, so the format is as documented
in the ooRexx reference.  For all the known options, you use the long
form of the option name in the options file.  I fixed up the --help
output a little so you can see what to use.

--help will look like this snippet:

 Generic option:
  -D    Define option.  Format must be: -Dname=value

 Test selection:
  -a  -DallTestTypes=bool           Include all test types
  -b  -DbuildFirst=bool             Build external binaries before running tests
  -B  -DforceBuild=bool             Force building (implies -b)

So, take the -b, build first option.  The long name of the option is:
'buildFirst'  To use the long name on the command line you would use
the Define option format: -DbuildFirst=1

To use that option in the options file you would use:

buildFirst=1

All the boolean type options take either 0 / 1 or false / true on the
command line.  Same as you would use in a .Properties object.  The
option name for the known options is case insensitive.

In the options file you can also define any option you want, just as
you could on the command line using -Dname=value  So, for instance
David could define in his options file:

smtp_server=xx.yyy.z.xyz
smtp_user=david
smtp_passwd=xxz

and then his socket tests would always run on that machine without
having to specify the values each time.

* Run a single test case.

Rick requested this for when someone reports a bug.  Rather than have
to cut and paste the failing test case into a Rexx program to reduce
the complexity, you can just specify the test case name on the command
line and only that test case will execute.

Now this would make the most sense to specify just executing 1 test
group and 1 test case name.  But, you can specify a list of test case
names and even run it against the entire collection of test groups.
Only the matching test cases will be executed.  Here is an example:

C:\ooTest>testOORexx.rex -f
ooRexx\base\runtime.objects\environmentEntries.testGroup -t test_true
Searching for test containers..
Executing automated test suite..

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:     REXX-ooRexx_4.0.0(MT) 6.03 16 Jun 2009
Addressing Mode: 64
ooRexxUnit:      2.0.0_3.2.0    ooTest: 1.0.0_4.0.0

Tests ran:           3
Assertions:          1
Failures:            0
  (Known failures:)  0
Errors:              0
Exceptions:          0
Skipped files:       0
Messages:            0
Logs:                0

File search:        00:00:00.000000
Suite construction: 00:00:00.000000
Test execution:     00:00:00.000000
Total time:         00:00:01.016000

If you look at the environmentEntries.testGroup file, you will see
that it does have a test_true test case with 1 assertion in it.

(The reason it says tests run is 3 is an anomaly in how the tests are
counted.  Each test suite is counted as a test.  So, there is 1 test
suite that contains all the tests.  In this case that suite contains 1
test suite that contains 1 test, the test_true test case.)

My plan was to get all this finished *and* documented this weekend.
Well, I didn't make it to the documentation, so ask me any questions
you need to.

--
Mark Miesfeld

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to