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..."
Paul
On Mercredi, d�ce 18, 2002, at 01:27 Europe/Brussels, Rodney Waldhoff wrote:
Pressure from applet-oriented clients (like you) is one good way to
address this. Perhaps adding a some sort of unit testing framework for
running regular Junit tests in a "secured" mode would be another. I'd be
willing to experiment with the latter if anyone else would like to
collaborate.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
