Agree with Jeremy on assertion usage, especially *assertion is not anything "user should be informed about"* which is exactly my point: assertion (failure) should *not* be user/TestCase expectation.
On 7/20/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
We covered assertions a little in the exception handling document which should be on the website but which I got from here: http://svn.apache.org/viewvc/incubator/tuscany/site/src/site/xdoc/ exception_handling.html?view=co To me, assertions are things that the developer declares should never happen at runtime. As in, "I thought about it and decided this could never happen but I decided to check anyway as I could be wrong." Enabling them when running tests is necessary to verify those assumptions. This is different from things that should not happen but which might through user error - like checking for a user passing in a null value to an API call and throwing a IllegalArgumentException rather than letting a NPE happen when you use the value. And different from things that might quite realistically go wrong and which your user should be informed about - such as an IOException when reading from a file. -- Jeremy On Jul 20, 2006, at 3:33 PM, Raymond Feng wrote: > For those who are interested, there's a nice article about java > assertions @ http://www.javaworld.com/javaworld/jw-11-2001/jw-1109- > assert.html. And the following is quoted from it: > > "Expressions within an assert statement should not produce side > effects, since doing so exposes program execution to potentially > different behavior with and without assertions enabled. You should > use assertions to produce more reliable programs, not less reliable > ones. > Finally, caution must guide the development of the expressions used > in assert statements. In addition to not producing side effects, > assertions should not alter normal program execution." > > I think I buy what the author says. > > Thanks, > > Raymond > > ----- Original Message ----- From: "Yang ZHONG" > <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, July 20, 2006 3:11 PM > Subject: Re: Java assertion related test case failures > > >> I hope our code are not designated to run in some specifically >> configured >> JVM. >> Since JVMs may turn assertion on or off, I'm not sure >> AssertionError should >> be an expected behavior in general. >> >> Dedicated exceptions and errors are much better protocol, e.g. >> IndexOutOfBoundsException and OutOfMemoryError give much more >> specific/useful info than plain AssertionError, not to mention >> assertion >> isn't really born for error reporting. >> >> On 7/20/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >>> >>> Assertions should be enabled when running our test cases. >>> >>> I have added an AssertionTestCase to the spi module that will cause >>> the build to fail if assertions are not enabled. >>> -- >>> Jeremy >>> >>> On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote: >>> >>> > Hi, >>> > >>> > I ran into some test case failures with the trunk code in both >>> > Eclipse and Maven (reported by my continumm build) related to the >>> > usage of java assertions. >>> > >>> > For example, in test case >>> > "org.apache.tuscany.spi.extension.ReferenceTestCase", we have the >>> > following test: >>> > >>> > public void testPrepare() throws Exception { >>> > TestReference ref = new TestReference(null, null, null); >>> > try { >>> > ref.prepare(); //[rfeng] We assume the assert will catch >>> > null before it moves on to NPE >>> > fail(); >>> > } catch (AssertionError e) { >>> > //expected // [rfeng] NPE is thrown if assertion is not >>> enabled >>> > } >>> > } >>> > >>> > By default, assertions are disabled by JVM unless you explicitly >>> > turned it on using "-ea" option on the VM (In Eclipse, you need to >>> > set the VM arguments either at the JRE or test case.profile level. >>> > For Maven, you may need to set MAVEN_OPTS to include -ea). As a >>> > result, the test case fails because it throws NullPointerException >>> > instead of AssertionError. >>> > >>> > Should we improve these test cases to be more robust? >>> > >>> > Thanks, >>> > Raymond >>> > >>> > >>> -------------------------------------------------------------------- >>> - >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> >>> >>> -------------------------------------------------------------------- >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> >> Yang ZHONG > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Yang ZHONG
