Paul Libbrecht wrote:
Having tests within applets looks perfect to me!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.
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..."
Jerome
(*) Warning I know nothing about XDoclet, just read a small article about it.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
