Re: [Oorexx-devel] Test units

[Rick M. <obj...@gm...>]

We'e been fairly good at writing new tests for the features we've
added, but we're sadly lacking in regression tests covering the older
features.  At this point, any tests added to the regression suite aids
us in getting closer to 4.0 release.

David and I had a similar experience in writing a lot of these tests.
You start to think that you're wasting your time because all of this
stuff just works already, when you'll suddenly discover something
unexpected with one of the test you write.  This happened repeatedly
for both of us.

Rick

On Sat, Feb 14, 2009 at 11:37 PM, Dan Carter <gwc...@ez...> wrote:
> Thanks, fellows.  The isA test is what I had in mind.  I will proceed.
> It seems to me that any tests are better than no tests, and that new
> test methods can be added when holes are found.
>
> I have been examining the source for the Class and the Object classes,
> and it is clear that this old coder ( I am not yet extinct, so I can't
> call myself a dinosaur) has much to learn about the ooRexx programming
> system.  Thanks for such clear and intuitive C++.  Even I can read it.
>
> If there are tests that will help with the release of 4.0 please shout.
> I can free you all up a little bit by writing them.
>
>
> -----Original Message-----
> From: Mark Miesfeld [mailto:mie...@gm...]
> Sent: Saturday, February 14, 2009 20:21
> To: Open Object Rexx Developer Mailing List
> Subject: Re: [Oorexx-devel] Test units
>
> On Sat, Feb 14, 2009 at 5:26 PM, Dan Carter <gwc...@ez...> wrote:
>> As Rick suggested I am (trying) writing a test unit for the Object
> class.
>> After studying Mark's Quick Start guide I think I understand what to
> do.
>
> Dan,
>
> (Well, I started to write this and then had to leave.)
>
> First, please do not get discouraged.  If we could get even one more
> person (yourself) to write a few test cases, I'd be ecstatic.
>
>> It seems to me that writing test cases involves exercising each method
> of a
>> class which has been instantiated into an object.
>
> That is a reasonable approach.  Especially for testing the classes.
>
>> Further, it looks to me
>> that a method should not be used until it has been tested.
>
> I would drop that assumption all together.
>
> The reality is we are testing ooRexx using ooRexx.  Now, some might
> say you can't do that, you need to start with a known working.  But,
> it works surprisingly well.
>
> If ooRexx was not working, you would never get to the test case.  The
> framework that executes the tests heavily exercises ooRexx to begin
> with.  When Rick first made the big merge of his new work for 4.0.0,
> we never got to the test cases, the framework did not work.  We just
> first fixed the bugs that running the framework uncovered, and then
> once it was going started fixing the bugs the test cases uncovered.
>
> We know ooRexx works, basically.  What the test suite does is exercise
> as many different code paths as we can devise.
>
> In my opinion, you should just try to have a test case for everything
> you can think of.  That way, if some small change breaks something, we
> are likely to find it.
>
> We had a bug where the empty method of Array did not work, under
> certain circumstances.  We had tests for the empty method, but we did
> not have a test that found that bug.  As I remember, this is the test
> I added that *would* have found the bug:
>
> ::method "test_empty_with_of"
>  a = .array~of('dog', 'cat', 'bird')
>  self~assertSame(3, a~items, 'array a must have 3 items')
>  a~empty
>  self~assertSame(0, a~items, 'array a must have 0 items after empty')
>  self~assertTrue(a~isEmpty, 'array a must be empty after empty')
>
> As you can see, the test uses a number of the Array methods.  Because
> of the way the framework works, there is no guarantee that the isEmpty
> or the items method has already been *proven* to work at the point
> this test runs.
>
> So, in addition to what Rick wrote, I would say go ahead and write
> some tests for new.  We know they will work, but just writing a simple
> test will get you started.  The test will most likely pass from now
> until eternity, but you never know.
>
> I would start with just this:
>
>  ::method test_object_new
>    obj = .Object~new
>    self~assertTrue(obj~isA(.Object))
>
>  ::method test_class
>    obj = .Object~new
>    self~assertSame(.Object, obj~class)
>
>> tc1 = .Object~new
>>
>> what will be in tc1 if the call fails?  Will it be the handle of the
> .NIL
>> object?  I am at a loss to figure out how to test the ~new method
> without
>> using other methods of the Object class.
>
> I say, just use other methods of the Object class.  Some of the
> simplest tests we have, are there as hindsight because of a bug we
> had, then wrote the test for the bug after the bug was fixed.  The
> empty method test is an example.
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------
> ------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>