commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [all] Commons SCXML 0.9 RC1 available
Date Thu, 27 Nov 2008 13:25:52 GMT
On 26/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Wed, Nov 26, 2008 at 6:20 AM, sebb <sebbaz@gmail.com> wrote:
>  > On 25/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
> <snip/>
>
> >>
>  >>  So, if and only if:
>  >>  a) the usage needs serializability (not all library uses do), and
>  >>  b) a DOM impl that isn't serializable is in use (such as Crimson)
>
> <snap/>
>
>  It turns out I left another clause out of the compound predicate
>  above, which is:
>
>  c) and if the SCXML documents define the XML data model via the
>  <datamodel> element.
>
>  (<datamodel> is optional ofcourse, hence the 'if')
>
>
>
>  >>  then it'd be necessary to switch to a more helpful parser.
>  >>
>  >>  In any case, the tests are meant to spew copious warnings to remind
>  >>  folks when the above is true, but they are not designed to fail since
>  >>  there is nothing in the library source that needs changing.
>  >
>  > Agreed that the source is not at fault - it is the test environment
>  > that is at fault.
>  >
>  > However, it means that the test does not exercise all the library code
>  > - it might fail to pick up genuine faults - so I think that should be
>  > regarded as a test failure.
>  >
>
> <snip/>
>
>  But we do test that all library code gets exercised :-)
>
>  Lets play out the scenario when the DOM impl isn't serializable (if it
>  is, thats no longer a scenario of interest for this discussion since
>  all is well):
>
>  (1) We run all tests that have nothing to do with serialization
>  (2) For tests that have something to do with serialization
>    (2a) We run those that do not use the XML <datamodel> element
>          (examples [1, 2])
>    (2b) We run those that use the <datamodel> element, but skip the
>           serialization because the DOM impl is not serializable
>
>  In (2a), we have already tested that serialization works for the rest
>  of the library. So if the DOM impl is replaced by a serializable one,
>  we can be reasonably certain that serialization will work in (2b). We

But one cannot be sure that the serialisation works correctly unless
it is actually performed. A class may serialise without an error, but
the serialsed form may not behave correctly.

That's why I think the test suite should generate at least one failure
if serialisation is not possible.

>  have already tested (2b) from a functional PoV in all aspects other
>  than serialization.
>
>
>
>
>  > The failure message should make it clear that the problem lies in the
>  > environment.
>  >
>
> <snap/>
>
>  But its not a concern for those who may choose to not use the
>  <datamodel> i.e. there are viable scenarios where it is acceptable to
>  not require a serializable DOM impl. Therefore, it should not be a
>  build failure (the message can be improved, as is very often true with
>  messages).
>
>  Thanks for bringing this up in detail -- I'm increasingly of the
>  opinion that we are doing the right thing.
>
>  -Rahul
>
>  [1] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/history-shallow-01.xml
>  [2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/history-deep-01.xml
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message