commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerome Lacoste @ BBC" <lacostej...@altern.org>
Subject Re: [BeanUtils] MethodUtils caching
Date Wed, 18 Dec 2002 10:24:43 GMT
Paul Libbrecht wrote:

> Having tests within applets looks perfect to me!
>
> The most simplistic approach would be to use appletviewer to run all 
> the jUnit tests. That would bring an amount of "failed" that would 
> force developers to flag their tests to be applet-friendly or not, 
> then presumably flag the functionalities as such.
>
> A better approach would be to run a webserver and have the applets 
> from there, I presume. Also, I am not a signed applet should not be 
> tested as well (i.e. I am not sure there is not a little bit of 
> security left within these which is again different from the simple 
> java command).
>
> Or... should we make an interace for jUnit tests "applet-friendly" or 
> such?
> I think the issue to manage here is close to a documentation/build 
> issue: it needs to be documented what is applet friendly and what is 
> not, and this has to be documented at least on a class-basis, 
> cascading through dependencies). Would there be a better approach than 
> just attacking unit-tests for this ?
>
> How much "unfriendly" to developers would this be ? I typically fear a 
> complete refusal: "This collection is not applet-friendly, period, 
> don't bother me with that..." 

I am perhaps completely out of understanding here, but it seems that 
XDoclet(*) could be used there. You tag the classes that are supposed to 
NOT work in applet/sandbox environement and there are automatically 
documented as such. All other classes are automatically tested under the 
'Sandbox test environment'. And failures are reported.

Jerome

(*) Warning I know nothing about XDoclet, just read a small article 
about it.


Mime
View raw message