[Objectscript-devel] [OBJECTSCRIPT] Issue #OBJS23 modified

[Rob C. <rob...@ma...>]

Issue OBJS23 (need unit test framework for oscript.jar) has just been modified by user rob...@ma...

You can view the issue detail at the following URL:
     <http://icandy.homeunix.org:443/scarab/issues/id/OBJS23>

The following modifications were made to this issue:

a few notes:
  1) at least some tests will need to run under both interpreter and compiler... one way to accomplish this would be to add a mechanism to flush the cached NodeEvaluators as we run, so the test driver could:

   oscript.OscriptInterpreter.useCompiler(false);
   import testfile;
   oscript.OscriptInterpreter.flushNodeEvaluatorCache();
   oscript.OscriptInterpreter.useCompiler(true);
   import testfile;
   oscript.OscriptInterpreter.flushNodeEvaluatorCache();

  2) at least some sub-tests could be table based, such as tests of the built-in operators... the table for binary operators would basically be a matrix mapping input parameters & operator to expected result/type/exception

  3) the test driver should find all the existing tests, so adding a new test is simply a matter of dropping it in the appropriate directory

  4) the test driver may be specific to oscript (ie. ode/chimera/oscom tests need not run in both compiled and interpreted mode), but the mechanism for launching it should be generic... ie build.xml looks for a test.os in the sub-tree being built, and if it exists will run it.  The last thing the test.os should do is:

   java.lang.System.exit(nerrs);   // result code is 0 (success) if no errors

  5) perhaps it would be a good practice to implement a test to demonstrate a bug as part of the procedure of fixing a bug... for tests that fall into this category, I suppose we could name the file after the PR, ie. OBJS23.os... I am not sure what the critera should be for deciding when to create a new file, vs. when to add the test to an existing file.  I guess we can play it by ear...