On 26/11/2008, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 6:20 AM, sebb <[EMAIL PROTECTED]> wrote: > > On 25/11/2008, Rahul Akolkar <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
