[
https://issues.apache.org/jira/browse/SCXML-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660887#action_12660887
]
Rahul Akolkar commented on SCXML-91:
------------------------------------
Pasting some comments from the dev list in JIRA as well:
* Comment #1:
The idea (verifying if the NSE is actually due to the DOM implementation) is
good.
I think this implementation (r731543) is fragile since:
(a) It relies on an exception message
(b) It only accounts for crimson, but in theory the package name could be
anything (by virtue of the Java endorsed standards override mechanism)
Lets retain the NSE catch blocks as before. Other changes look good.
* Comment #2:
WRT the directory creation, if you'd rather have the build fail if creation
fails, there would ideally be a nice message stating the problem (rather than a
generic x failures and y errors kind of thing) and additonally, there'd be a
build time switch that allows folks to say "we don't care about serialization"
which would cause the build to succeed (this could also help the NSE catches
you are looking at eliminating -- all NSEs could then cause tests to error out
by default). So maybe the approach of providing such a switch helps both cases
we're discussing.
> Test case bugs
> --------------
>
> Key: SCXML-91
> URL: https://issues.apache.org/jira/browse/SCXML-91
> Project: Commons SCXML
> Issue Type: Bug
> Affects Versions: 0.9
> Reporter: Sebb
> Fix For: 0.10
>
>
> Test cases are difficult to debug if they fail.
> This is because many test cases catch Exception, and don't report it fully.
> Test cases should only catch a (specific) Exception if the test is expected
> to generate one, and should otherwise throw the Exception.
> Several test cases report problems to System.out or System.err and carry on
> processing.
> For example, serialisation errors are largely ignored, and
> SCXMLTestHelper#testExecutorSerializability() ignores IO errors.
> Testing generates a lot of output, some of which appears to be errors (e.g.
> stack traces) yet the test passes.
> Ideally tests should suppress output stack traces which are expected during
> testing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
