From: Rick M. <obj...@gm...> - 2008-10-09 15:16:24
|
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 <mie...@gm...> wrote: > On Thu, Oct 9, 2008 at 7:57 AM, Rick McGuire <obj...@gm...> 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |