This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
ok so i want to give a preface that this wasnt my idea but i "must" be able to do regular asserts in order to test code inside an applet (like very simple stuffs that can be covered by the java Asserts , however in order to view the results it would be highly favored if i could have junit collect it due to junits very nice html list of erros and failed and passed tests).
this is what i did
i made an object lets call it FOO that holds AssertionErrors (you can populate it and "run it" which prints out all of the erros and their stack traces and you can print out the garbage (anything that might have been stored in there that isnt an assertion error and clear all of the garabage). Now rather than just calling the run method of this object at the end of my applet i would like to be able to initiate these testing protocols from outside the applet.
the only thing i was thinking of that i know would work is making this FOO class a static class and then having a driver call its run method and show all the exceptions stored in it with the respective stack trace. (but i still wont have the nice junit html output).
however is there any way i could keep FOO as a non static class populate it in the applet and some how send it to a junit class to pull all the garage out of it and show that as errors and all the AssertionErros in it as failed tests so i have junits nice html display sheet?
Even though im marked for death I will spark till i loose my breath
Amaru, The static class thing sounds feasible. (Although still a hack.) My personal advise would be to ask the person who required the regular Java assert approach and ask what he/she thinks you should do. Presumably that person has thought about the idea since that person is mandating it.
well really i dont think the person knows 100% what they want, they just want any testing in the applet which is pretty hard to test in my opinion (well all i know how to test is the components it works with but the applet itself is pretty hard (i even looked at jmeter but thats something for another day because its not focused on testing the applet it at best is could only tell me if the applet is a source of poor performance on other resources, i never did any unit testing focused on applets, its mostly been with databases and java interacting with them (through ejbs or spring ect)).
so in reality i think im just going to do some regression testing and keep it below the surface of the gui (no watir or selenium stuff).
but i was wondering if there are any other ways to test an applet or any good sources to look at.
the person mandating just wants any tests to test the applet for the sake of testing, however they would prefer if they had them similiar to the other unit testing (in those junit html pages).
author & internet detective