commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SCXML-91) Test case bugs
Date Mon, 05 Jan 2009 20:07:44 GMT

    [ 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.


Mime
View raw message