You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2006/07/20 18:36:30 UTC
Java assertion related test case failures
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Yang ZHONG <le...@gmail.com>.
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 <jb...@apache.org> 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"
> > <le...@gmail.com>
> > To: <tu...@ws.apache.org>
> > 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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Yang ZHONG
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Java assertion related test case failures
Posted by Jim Marino <jm...@myromatours.com>.
These test cases were my bone-headed mistake...What they should be
doing is testing that prepare() executes properly so I'll fix them
once I get a couple of other checkins cleared out.
That said, we really ought to run mvn was assertions on as we need to
verify that assertion checking is done properly. For example, there
have been times in the past when assertion checking was incorrectly
done (i.e. threw errors for legitimate cases) and problems arose when
someone ran with -ea.
Jim
On Jul 20, 2006, at 4:57 PM, Raymond Feng wrote:
> I'm not sure what happens to the continumm build which underneath
> runs maven. It seems that assertions are not enabled for the test
> cases by default and I have to set "-ea" in the "mvn.bat" so that
> the latest code can be built successfully.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jeremy Boynes"
> <jb...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Thursday, July 20, 2006 4:37 PM
> Subject: Re: Java assertion related test case failures
>
>
>> On Jul 20, 2006, at 4:14 PM, Raymond Feng wrote:
>>
>>> If the purpose of the test case is to verify the "assert", I
>>> suggest that we use "ClassLoader.setClassAssertionStatus
>>> (targetClassName, true)" to make sure "assert" is on before the
>>> target class is initialized (for example, in a static block or
>>> TestCase.setUp()) instead of requesting the whole JVM to be
>>> launched with "-ea". Making sense?
>>>
>>
>> I was thinking that when running testcases we want do assertions
>> on across the entire VM so that any problems in peripheral classes
>> would cause the test to fail. As in, all tests should pass if
>> assertions are enabled so let's test that assumption so that we
>> can't mistakenly run the tests with assertions off. IMO it is not
>> a class-by-class thing.
>>
>> In the maven build assertions are enabled in the surefire plugin
>> so tests should always run with them on.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Raymond Feng <en...@gmail.com>.
I'm not sure what happens to the continumm build which underneath runs
maven. It seems that assertions are not enabled for the test cases by
default and I have to set "-ea" in the "mvn.bat" so that the latest code can
be built successfully.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, July 20, 2006 4:37 PM
Subject: Re: Java assertion related test case failures
> On Jul 20, 2006, at 4:14 PM, Raymond Feng wrote:
>
>> If the purpose of the test case is to verify the "assert", I suggest
>> that we use "ClassLoader.setClassAssertionStatus (targetClassName, true)"
>> to make sure "assert" is on before the target class is initialized (for
>> example, in a static block or TestCase.setUp()) instead of requesting
>> the whole JVM to be launched with "-ea". Making sense?
>>
>
> I was thinking that when running testcases we want do assertions on
> across the entire VM so that any problems in peripheral classes would
> cause the test to fail. As in, all tests should pass if assertions are
> enabled so let's test that assumption so that we can't mistakenly run the
> tests with assertions off. IMO it is not a class-by-class thing.
>
> In the maven build assertions are enabled in the surefire plugin so tests
> should always run with them on.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 20, 2006, at 4:14 PM, Raymond Feng wrote:
> If the purpose of the test case is to verify the "assert", I
> suggest that we use "ClassLoader.setClassAssertionStatus
> (targetClassName, true)" to make sure "assert" is on before the
> target class is initialized (for example, in a static block or
> TestCase.setUp()) instead of requesting the whole JVM to be
> launched with "-ea". Making sense?
>
I was thinking that when running testcases we want do assertions on
across the entire VM so that any problems in peripheral classes would
cause the test to fail. As in, all tests should pass if assertions
are enabled so let's test that assumption so that we can't mistakenly
run the tests with assertions off. IMO it is not a class-by-class thing.
In the maven build assertions are enabled in the surefire plugin so
tests should always run with them on.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Raymond Feng <en...@gmail.com>.
If the purpose of the test case is to verify the "assert", I suggest that we
use "ClassLoader.setClassAssertionStatus(targetClassName, true)" to make
sure "assert" is on before the target class is initialized (for example, in
a static block or TestCase.setUp()) instead of requesting the whole JVM to
be launched with "-ea". Making sense?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, July 20, 2006 4:00 PM
Subject: Re: Java assertion related test case failures
> 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"
>> <le...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>> >
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Yang ZHONG
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Jeremy Boynes <jb...@apache.org>.
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"
> <le...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>>
>> Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Raymond Feng <en...@gmail.com>.
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" <le...@gmail.com>
To: <tu...@ws.apache.org>
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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Java assertion related test case failures
Posted by Yang ZHONG <le...@gmail.com>.
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 <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Java assertion related test case failures
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org