Unfortunately, some of the APIs that are getting tested are the ones
that intercept SAY/TRACE statements, so relying on console output is a
bit of a problem. That's why I was suggested using a named queue,
since the things being tested won't interfere with named queues. I
was thinking something like this from the driver end:
resultQueue = self~getExternalResultQueue -- get the target result queue
'runtTests TestFunctionExit THISISANOPTIONSTRING
testTypeMarshal.rex" -- invoke the test runner
self~processExternalResults(resultQueue) -- process the return results
Then the code that ends up getting invoked (in testTypeMarshal.rex)
would do things like:
ExternalFrameWork~assertSame(123, TestIntArg(123), .line, "Testing
arguments")
The assertSame would push on to the named queue either
PASS 123 Testing Arguments
or
FAIL 123 Testing Arguments
The infrastructure could potentially have ERROR lines for unexpected
syntax errors as well.
Then the processExternalResults method would read all of the lines
from the external queue and log them (and raise the appropriate
failure conditions if there are FAIL or ERROR recodes). Ideally, I'd
like to have all of the FAILs or ERRORs be logged before raising a
failure assertion rather than stop with the first one.
I hope this makes what I'm trying to do a little clearer. I'd like to
have the code that handles assertion tests be no more than a single
line in the test code, and because of the nature of how some of this
stuff runs, a lot of the assertions will get made in top level program
code rather than executing as methods of a testcase subclass, which is
another complication. Also, by making these class methods, I can
actually raise assertions from the C++ test code as well as the ooRexx
code, which will make some of the tests easier to write.
Rick
On Thu, Oct 9, 2008 at 10:21 AM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 9, 2008 at 6:47 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
>> I've been trying to write some tests for the RexxInstance APIs and the
>> new style exit handlers. For the most part, having an external
>> function or method that gets called by the main test code is not going
>> to work. A lot of these tests really need to be run in a separate
>> process. Right now, my approach will be to have a single large .exe
>> file that implements multiple test variations that are invoked with
>> command line arguments. Generally, the arguments would be something
>> like this:
>>
>> runTests testid options program arguments ....
>
> Rick,
>
> Let me preface this by saying, I've never used any of these APIs so it
> could be that I'm missing something. That said, the way I would
> handle this is as follows.
>
> You would have your external binary that implemented whatever APIs you
> are testing.
>
> >From within the existing framework you execute the binary in a
> separate process passing whatever arguments you want to test different
> things. The framework captures both the return code from the external
> binary and also any console output. Within the existing framework you
> assert that the return code is what you want. You can also assert
> that the console output is what you expect.
>
> There are already utility functions in the framework to make it easy
> to run external programs, capture the return code, and capture the
> console output.
>
> I have use that type of testing very successfully in the past.
>
> The utility functions may need to be enhanced, they are just a start
> based on stuff I have done in the past.
>
> For example, we have that one sample program that starts up the
> interpreter, takes a string and has the interpreter reverse it. (I
> think, as I recall it is something like that.) I believe that sample
> uses some of the APIs you are talking about.
>
> So you have something like this:
>
> ::method test_MarksMadeUpExit
>
> output = .array~new
> cmd = 'reverseAndExit -r "trap door"'
>
> ret = issueCmd(cmd, output)
>
> -- reverseAndExit with r option returns
> -- number of chars in string
> self~assertEqual(9, ret)
>
> -- self~assertSame("rood part", output[1])
>
> By varying the return code and output, I think you could test whatever you
> want.
>
> In addition, since I don't know these APIs, I was hoping we would
> write a number of simple executables that each tested different
> things, rather than one monolithic executable that did everything.
> However, if by passing arguments to one executable you can test a
> bunch of different stuff, then this method still works fine.
>
> --
> Mark Miesfeld
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
