Like I said, heck no (our tests run on forever if you haven't noticed.
The ones I'm doing for formulas will put you to sleep!) go right ahead.
However I don't think your approach will work necesarily. At least it
seemed the error condition I got was not an exception but a message from
the OS that the link wasn't satisfied. I'm not sure its passed down to
the program (in which case I'd regard that as a bug), I just didn't
*see* anything that looked like an exception. I think it caused a java
exit, but I don't remember for sure. Its fairly easy to add properties
to the JVM for the purpose of the build. We set one so the unit tests
could find their data. We could set one based on an environment
variable for run-x-tests or something. Anyhow, as long as the test is
named so that its obvious it is dependant on AWT (like by postfixing
AWT) then it makes no nevermind to me.
-Andy
Drew Varner wrote:
>I am talking about implementing dynamic class loading for unit testing. I am
>assuming nobody minds the performance hit for unit tests? This would allow the
>tests to run on a machine with X. It would gracefully leave the test on a
>headless machine. On a machine where X wasn't present, the test would catch the
>appropriate exception. I think there'd be one thrown.
>
>try
>{
> //used quotes this time
> Class klass = Class.forName("java.awt.BufferedImage");
>}
>catch (Exception e) //I'd catch the right exception in real code
>{
> //the class is not available because we are
> // on a headless machine
> elegantExitFromTest();
>}
>
>This way we wouldn't have to rely on shell script to test the code on a
>headless box. Best of both worlds thing.
>
>Is a performance hit during unit testing a big deal? I'd consider it outside of
>the performance critical portion of the program.
>
>- Drew
>
>Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>:
>
>>Right, but umm, when that runs, X still loads right? or maybe you're
>>planning a property to turn it off? You'll need the quotes of course.
>>
>>-Andy
>>
>>Drew Varner wrote:
>>
>>>I'd prefer something more elegant. How about I use...
>>>
>>>Class.forName(java.awt.BufferedImage)
>>>
>>>and catch exceptions in the test and handle it gracefully? That way we
>>>
>>don't
>>
>>>have to hack apart the script for headless servers.
>>>
>>>- Drew
>>>
>>>Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>:
>>>
>>>>No, I have no problem with it. It would be nice if you put some kind
>>>>
>>of
>>
>>>>easy to auto delete filename for it. Something like testBlaBlaAWT so
>>>>that those who for some reason choose to build on a headless server
>>>>
>>can
>>
>>>>find . -name "*AWT.java" -exec rm '{}' ';' -- but this isn't something
>>>>that would affect me as I'd have no reason to run the unit tests on my
>>>>server. I guess its possible we may one day move the nightly builds
>>>>
>>to
>>
>>>>a commodity server, so best do something that can be easily removed
>>>>
>>via
>>
>>>>a script if you don't mind.
>>>>
>>>>Thanks,
>>>>
>>>>-Andy
>>>>
>>>>On Sat, 2002-04-27 at 22:10, Drew Varner wrote:
>>>>
>>>>>Does anyone have a problem with me importing java.awt.BufferedImage
>>>>>
>>>>for the
>>>>
>>>>>purposes of a JUnit test?
>>>>>
>>>>>I'd like to examine the image (check width, height, etc.) via the
>>>>>
>>>>Image methods
>>>>
>>>>>as a sanity check when extracting the byte array. It seems like a
>>>>>
>>good
>>
>>>>way
>>>>
>>>>>tomake sure the byte array isn't garbage. I don't think JAI or other
>>>>>
>>>>standard
>>>>
>>>>>Java Image toolkits support WMF files. I'll investigate more.
>>>>>
>>>>>Drew
>>>>>___________________
>>>>>Drew Varner
>>>>>[EMAIL PROTECTED]
>>>>>
>>>>--
>>>>http://www.superlinksoftware.com
>>>>http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
>>>>Document
>>>> format to java
>>>>http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
>>>> - fix java generics!
>>>>The avalanche has already started. It is too late for the pebbles to
>>>>vote.
>>>>-Ambassador Kosh
>>>>
>
>___________________
>Drew Varner
>[EMAIL PROTECTED]
>
