Re: SCXML Test Plan Coverage

The purpose of these tests is to show that  the specification can be 
implemented interoperably, not to show that a given implementation 
performs correctly on all code paths.  In general, we are allowed to 
assume 'reasonable' implementations, so if we show that multiple 
implementations interpret <final> as a child of a compound state the 
same way, it is OK to assume that they will handle it as a child of 
parallel states the same way.


On 6/30/2014 4:56 PM, Gavin Kistner wrote:
> Now that I have finished my implementation report, running every 
> mandatory test that I support, I thought I'd share updated code 
> coverage results for the main runtime.
>
> https://gist.github.com/anonymous/c81c0275212944ad9cbf
>
> You can ignore any lines with ****0 at the beginning that relate to 
> <invoke> or <send> to an external target. These tests were skipped, 
> and thus not exercised in the algorithm. However, there is one 
> interesting takeaway:
>
> The isInFinalState() function only ever tests compound states, never 
> any parallel states or atomic states. (Lines 430-433.) We should add 
> SCXML tests that exercise this functionality. I guess that this means 
> that we have no test for <final> states as descendants of a 
> <parallel>? Or is it algorithmically impossible to reach these code 
> branches (in which case the implementation of isInFinalState could be 
> simplified)?
>
> (The 0 hits on line 442 of getTransitionDomain() is, I now see, an 
> implementation flaw on my part (testing for nil instead of empty set).)
>
>
> --
> (-, /\ \/ / /\/

-- 
Jim Barnett
Genesys

Received on Tuesday, 1 July 2014 15:24:12 UTC