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
