[Oorexx-devel] Proposed major change to ooRexxUnit

[Mark M. <mie...@gm...>]

All,

I am planning on the following major change to ooRexxUnit, and by
default our test suite.  This change comes primarily from a comment
Rick made to me some time back.

He said something like: the one major complaint I have about
ooRexxUnit is that it doesn't show the line number in the file where
the error occurred.

I'm going to fix that, but it means changing the args passed into the
assertXXX() methods.  Since I'm going to change the args, I'm going to
take the opportunity to move the optional 'message' arg to the last
arg position.

The signature for all the assertXXX() methods will be:

assertXXX(.line, expected, actual, <msg>)

or

assertXX(.line, actual, <msg>)

Depending on if it is something like assertSame() or assertTrue().
msg is optional, the other args will be required.

In my opinion this will make writing test cases a lot easier for the
person writing them and make it a lot easier for the person trying to
examine test failures.

I want to try and merge the work I have been doing in the incubator,
including this change as soon as feasible, so if there are any
comments, please speak up.  (I have a brute-force parser that I will
use to rewrite all the existing .testGroup files to change the
assertXX() statements as they are currently written.  I have that
working, so it is not a lot of manually editing to make this change.)

A little more explanation.

Take a typical section of code from a .testGroup:

::method "test_GETWHOLE_DEFAULT"
   p=.properties~new
   key="a"
   val=1
   self~assertEquals("subtest_01", val, p~getWHOLE(key, val))
   val=0
   self~assertEquals("subtest_02", val, p~getWHOLE(key, val))

The primary purpose of the message argument in JUnit is to add some
clarification as to what the test is doing.  The msg argument is
*only* used if it really clarifies something that is not clear from
the test itself.

However, we have almost never used it for that purpose.  Instead it
has been used to help locate where a failure happened.  All the
"subtest_xxx" statements are really useless, if we know the line
number and the file name where the failure has happened.  Plus, when
you start hard coding numbers, it becomes a nightmare when you make
changes.  Do you renumber every subtest_xxx just so you can insert a
sub_test004 somewhere?  Do you just skip the renumbering, do you just
not add the test ... ?

The above asserts will be changed to:

   self~assertEquals(.line, val, p~getWHOLE(key, val))
   val=0
   self~assertEquals(.line, val, p~getWHOLE(key, val))

Now, you might say how is that easier, instead of typing "subtest_01"
I now have to type .line?  Well, .line is easier to type than
"subtest_01" and move importantly, if you have a decent editor you can
set up a macro expansion to eliminate typing .line altogether.  For
instance, in SlickEdit you get create an alias of

!true

That expands into:  self~assertTrue(.line,

Then all you have to type is !true to get the assert started.  This
would really make writing asserts easier.

In the print out after a test, instead of:

[failure] [20080105 10:43:46.130000]
  Test:   TEST_MULTIPLE_INHERITANCE_WITH_MULTIPLE_METACLASSES
  Class:  Class.testGroup
  File:   E:\work.ooRexx\ooRexxUnit\3.x\ooRexx\base\class\Class.testGroup
  Failed: assertEquals
    Expected: [['123.'], identityHash="257979828"]
    Actual:   [['231.'], identityHash="238662007"]
    subTest_01

You could have:

[failure] [20080105 10:43:46.130000]
  Test:   TEST_MULTIPLE_INHERITANCE_WITH_MULTIPLE_METACLASSES
  Class:  Class.testGroup
  File:   E:\work.ooRexx\ooRexxUnit\3.x\ooRexx\base\class\Class.testGroup
  Line: 453
  Failed: assertEquals
    Expected: [['123.'], identityHash="257979828"]
    Actual:   [['231.'], identityHash="238662007"]

or any number of variations

[failure] [20080105 10:43:46.130000]
  Test:   TEST_MULTIPLE_INHERITANCE_WITH_MULTIPLE_METACLASSES
  Class:  Class.testGroup
  File:   E:\work.ooRexx\ooRexxUnit\3.x\ooRexx\base\class\Class.testGroup
(Line: 453)
  Failed: assertEquals
    Expected: [['123.'], identityHash="257979828"]
    Actual:   [['231.'], identityHash="238662007"]

In SlickEdit you can easily set it up to run the test suite within the
editor with the output going to the build window.  And then double
click on the 'File:' line above to go directly to the test failure to
look at it more closely.

--
Mark Miesfeld