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...
|
