On Sat, Feb 14, 2009 at 5:26 PM, Dan Carter <gwcar...@ezlink.com> 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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
