Ok, the test itself will involve invoking a binary program. That
binary program will typically do the following:
1) Call RexxCreateInterpreter to create an interpreter instance. The
options string will control different aspects of how this environment
will work. For example, when testing the different exit types, there
are 3 possible actions each exit will take: 1) do nothing (allow the
default processing to proceed), 2) handle the event (prevent default
processing from proceeding) or 3) raise a system error. The options
string will configure how the exit will function, so I've got fine
grained control without having to create a bajillion different test
variations in the binary.
2) Run some test program that drives some activity that will test
different aspects of the APIs. For example a very simple one would
just to a simple
say "Hello World".
A more complicated one will duplicate a lot of the testing done with
the API tests. But in this case, rather than call functions
implemented in a package, I'll be using a very sophisticated function
exit that will intercept and implement a number of external function
calls. This will be used to test the capabilities of the
RexxExitContext defined APIs.
3) If there are unexpected errors that the binary traps when it calls
the program, it will need to raise some sort of assertion events
beyond just a function call. Fortunately, it will be able to use the
same class methods the ooRexx code uses to do this.
So, on any individual invocation of my external binary, a lot of
different activities will take place. There will be API code tested,
and a lot of that API activity will be driven by ooRexx code that is
part of the test being executed.
Rick
On Thu, Oct 9, 2008 at 11:02 AM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 9, 2008 at 7:57 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
>> One more point. The programs that get invoked by the out-of-process
>> binaries should be just files that reside in the file system. I'd
>> prefer to not have to write them to disk each time the test is
>> executed. I don't think this is going to be a problem, as we already
>> have a precedent for things like the API tests where with have a
>> .testGroup file and a .cls file. In my case, I'd have a .testGroup
>> file and n number of invoked programs. We can give these some special
>> extension if we wish.
>
> Yeah, I don't think that should be a problem.
>
> I'm not sure what you mean by "invoked programs" for these files
> though. Are they binary executables, ooRexx programs, or ... ?
>
> --
> 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
