> On 2 May 2017, at 22:02, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> If the test was being written new I would advocate to add messages that
> reflect the semantics of
> the test case, not the exception message.
>
> But ": Must throw ClassCastException for parameter which is not Comparable."
> in Empty navigableMap is much more useful.
Well, okay. I think it's a fair point to have this option available. I for one
once agreed and fully accepted Joshua Bloch's passage [1] on this:
"...While it is critical to include all of the pertinent "hard data" in the
detail message of an exception, it is generally unimportant to include a lot
of prose. The stack trace is intended to be analyzed in conjunction with the
source files and generally contains the exact file and line number from
which the exception was thrown, as well as the files and line numbers of all
other method invocations on the stack. Lengthy prose descriptions of the
failure are generally superfluous; the information can be gleaned by reading
the source code.
The detail message of an exception should not be confused with a user-level
error message, which must be intelligible to end users. Unlike a user-level
error message, it is primarily for the benefit of programmers or field
service personnel for use when analyzing a failure. Therefore, information
content is far more important than intelligibility..."
> And wrapping exceptions in exceptions makes debugging much harder, because
> it requires unwrapping the context and figuring out what the test was trying
> to
> do and which was the relevant source line. Here I would advocate for the
> test author
> to make sure the diagnostic information is direct and informative and not
> obscured
> by stack traces and too much irrelevant detail.
I think a stacktrace is an enormously valuable piece of information to have in
logs of a test run. It shows you where exactly a thing happened without any
effort on your side.
One more thing. I don't know much about TestNG, but IIRC JUnit used
java.lang.AssertionError (or its subclass) for the framework's internal
mechanics. So to a various utilities (test report generators, test report
analyzers, etc.) an AssertionError thrown from inside a test meant a specific
thing. Quite different from what any other Throwable meant. I'm not saying I
agree with this design (it probably should've been a separate private exception)
I'm just saying. TestNG might use a similar approach.
> I should probably try to file a bug against TestNG.assertThrows to add a
> variant with
> a message. Many/most of the TestNG asserts have variants with messages.
+1
Thanks.
--------------------------------------------------------------------------------
[1] Effective Java(TM), Second Edition, Item 63
