Yes, generally speaking this will cause any native asserts (i.e. assert (foo == bar)) to throw AssertionError. Normally neither JUnit nor production code catches errors, so they will propagate up through the JUnit test methods and register as "JUnit errors" (as opposed to the "failure" category when a JUnit assert method fails).
I will give it a try and report back.
Thanks,
Cameron
----- Original Message -----
From: david_williams@xxxxxxxxxx
To: wtp-releng@xxxxxxxxxxx
Sent: Monday, August 23, 2010 4:02:06 PM GMT -08:00 US/Canada Pacific
Subject: Re: [wtp-releng] Running JUnit's with -ea
That should work. Shouldn't cause any
problems. Should we turn this on for all junit testing? Even if so,
why don't you give it a try first, and see how it goes.
I assume if the assert is caught that
throws an exception which then shows up as a junit failure?
Sounds great ... maybe you could teach
the rest of us if/when this is a good technique/method?
Thanks.
| From:
| Cameron Bateman <CAMERON.BATEMAN@xxxxxxxxxx>
|
| To:
| <wtp-releng@xxxxxxxxxxx>
|
| Date:
| 08/23/2010 06:41 PM
|
| Subject:
| [wtp-releng] Running JUnit's with -ea
|
| Sent by:
| wtp-releng-bounces@xxxxxxxxxxx |
We have recently discovered a bug that would
have been caught much earlier if we had been running our JUnit tests with
assertions enabled (-ea VM flag). I want to add the -ea option to
all of our JSF Tools JUnit tests. I assume the best way to do this
is to edit each test.xml with an extraVMArgs property.
Are there any known issues with taking this approach? Any reason
not to proceed with this approach?
Thanks,
Cameron_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
