I have seen that, but I'm not entirely sure if that is what we need...
that framework may help, but that is really only a tiny part of the
entire problem, which is coming up with what to test, and how to test
it adequately with a compact and maintainable test suite. I think
different specific areas in the scripting engine have fairly specific
requirements:
parser/compiler/interpreter: each test here needs to run twice,
once with the compiler and once with the interpreter. This is the area
that I am the most fuzzy on... I can obviously have tests for all the
basic grammar productions (for loop, if statement, try/catch/finally,
etc.), but to some extent there needs to be tests that combine
productions... for example at one point I discovered a bug with nested
try/catch/finally's. This is the main reason that I'd like to study
how other languages handle this.
data/builtin-operators: fairly simple for unary operators, but
for binary operators there are n^2 combinations of input types ->
result... maybe a good candidate for something table based. This
probably does not need to be run in both interpreted and compiled mode.
java<->script bridge: convert script types to java types and
visa versa... again, probably can be table based, and probably doesn't
need to be run in both interpreted and compiled mode
misc: abstract-filesystem, node-evaluator
caching, etc.
On Tuesday, January 28, 2003, at 01:00 PM, Brad Hyslop wrote:
> By the way, there is a unit test framework somewhere in there: it is
> what is used to unit test the series. Its a java version of something
> I developed for C++, and I was relatively happy with how it came out.
> See:
>
> /vobs/java/esf/dot/series/StringSeriesUnitTest.java
>
>
>
>
> Rob Clark wrote:
>
>> You can view the issue detail at the following URL:
>> <http://icandy.homeunix.org:443/scarab/issues/id/OBJS23>
>>
>> Type : Enhancement
>> Issue Id : OBJS23
>> Reported by: Rob Clark
>> rob...@ma... - (rob...@ma...)
>>
>> Details:
>>
>> Headline: need unit test framework for oscript.jar
>> Description: We need a more extensive regression test for
>> ObjectScript. Not entirely sure what the scope of this is, but we
>> should look to other languages (perl comes to mind) to see how they
>> handle this sort of thing.
>>
>> Severity: Minor
>> Functional Area: other
>> Status: New
>>
----------------------
Rob Clark
Texas Instruments, Inc.
(858)552-2946
ro...@ti...
----------------------
|
