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 Fri, 28 Nov 2008 15:05:15 GMT
On 27/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
>
>  On Nov 27, 2008, at 8:25 AM, sebb <sebbaz@gmail.com> wrote:
>
>
> > 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.
> >
>
>  I'll be brief, since I dislike typing on the phone :-)
>
>  We have numerous tests and data points for actual serialization that are
> known to work.
>
>
>
>
> >
> > That's why I think the test suite should generate at least one failure
> > if serialisation is not possible.
> >
> >
>
>  We disagree given the specifics I've mentioned earlier in this thread.
>

I'm not saying that the tests need to be fixed for 0.9, however I
think they need to be fixed for any subsequent release. I'm happy to
provide patches and/or update trunk to achieve this.

IMO, it's important that tests can be run using some form of CI (e.g.
Continum or Gump) and for the tests to report a failure if there are
any problems. Therefore it is important that any testing errors are
reflected in the final testing status, not just in the debug output.

Further, if the test is run on a supported version of Java (e.g. Sun
Java 1.4) and some of the tests for that version of Java cannot be
run, this should be regarded as a test failure.

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