commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [SCXML] test should fail if serialisation work dir cannot be created
Date Tue, 06 Jan 2009 21:55:39 GMT
On 06/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Mon, Jan 5, 2009 at 5:40 PM, sebb <sebbaz@gmail.com> wrote:
>  > On 05/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >> On Mon, Jan 5, 2009 at 3:52 PM, sebb <sebbaz@gmail.com> wrote:
>
> <snip/>
>
> >>  >
>  >>  > Not sure I know how to do that in Maven. Why not do a single test for
>  >>  > NSE and skip any further serialisation tests if the the initial test
>  >>  > fails?
>  >>  >
>  >>
>  >> <snap/>
>  >>
>  >>  You mean single JUnit test? That'll cause the build to fail on JDKs
>  >>  like Sun 1.4 (unless the tests are skipped), which seems suboptimal
>  >>  given its an optional feature users may not need and an environment
>  >>  configuration, rather than code, issue.
>  >
>  > Yes, the idea would be to use a separate JUnit test to probe for the
>  > specific NSE error and skip the other tests that would fail.
>  >
>  > The NSE exceptions would then no longer need to be caught.
>  >
>  > This would make it much easier to detect other serialisation errors,
>  > e.g. if any of the classes are updated in future. There would be no
>  > need to check what class was involved - i.e. the present "fragile"
>  > check would not be needed.
>  >
>
> <snap/>
>
>  Apart from the details of conditionally turning off certain tests once
>  the surefire plugin sets off (which I'm not aware of) ...
>
>  Ideally, we don't want to skip those tests entirely, we just want to
>  skip the serialization round trips in those tests once we detect the
>  specific NSE due to the DOM impl.
>
>  Each of those tests takes the form of functional testing interspersed
>  with serialization testing, this best emulates real world scenarios,
>  IOW:
>
>  1. test something
>  2. do a serialization round trip
>  3. test something else assuming state at end of 1
>  4. do another serialization round trip
>  ...
>
>  So we'd want to skip 2 and 4, but keep testing 1 and 3. Which is what
>  we do now. Ofcourse, at any point, if the JDK DOM impl isn't
>  serializable, then the endorsed standards override mechanism can be
>  used to change that and fully run all the tests with serialization.
>  Your point of making it easier to detect other serialization errors on
>  such a JDK is well taken.
>
>
>
>  >>  When I weight the pros and
>  >>  cons of a build failure vs. current outcome (warnings to console) in
>  >>  this context, the latter seems better to me.
>  >>
>  >
>  > Now that the test output is shorter, the serialisation warning
>  > messages stand out better,
>
> <snip/>
>
>  Yup, thats a good thing, thanks :-)
>
>
>
>  > but I think NSEs which are not caused by
>  > the faulty Sun 1.4 DOM should cause failures.
>  >
>
> <snap/>
>
>  OK, so what you added to trunk does that. I guess we can retain the
>  crimson check as-is and keep refining it as and when it breaks with
>  other obscure JDKs and configurations you and I haven't tested on.
>

Great!

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