Forums

by vera >> Thu, 19 Sep 2002 2:41:15 GMT

Hi,

I'd like to hear from any users of JadeUnit testing framework. I just heard about it yesterday and I am curious if there are any users out there who have been using it for some time and what's your opinion.

Thanks,
Vera

by kevin_alcock >> Mon, 14 Oct 2002 14:42:49 GMT

How about JadeUnit versus JadeScript? I like the idea of JadeUnit (I do have a biased opinion) but most jade developers are using a different test framework, which is JadeScript. Being a pusher of agile development with things such as extreme programming (XP) & refactoring, I would like to everyone to use JadeUnit, but I have since come to the realization that it's the act of doing the test not how the test is executed which is important. The creation of test scripts promotes domain-presentation separation. This allows easier implementation of another view or interface and a centralization of business logic. In the end this should make our (the Jade developers) life much easier.

Thanks for the rant,

Kevin
--
kalcock@jadedirect.com
Jade Direct USA Corporation
303 Research Drive, Suite 200 Ph: (770) 248 1382 ext. 202
Norcross, GA 30092 fax: (678) 291 0352

by allistar >> Mon, 14 Oct 2002 22:30:08 GMT

I think that for any testing framework to be worthwhile it needs to simulate both the GUI and the database back end. Doing just the model
is not enough as it doesn't take into account the consequence of displaying data in the GUI (which has implications to stress testing
as objects are locked, unlocked and fetched).

I don't know much about the JadeUnit mechanism, but because of the
above I think that any decent stress tester needs to drive the GUI.
The advantage of this is that you don't have to "repackage" your GUI
into a non-GUI framework to simulate the object locks etc.

The drawback of driving the gui is that you are limited to one tester
per PC (running more than one has consequences when focus is shifted
from one tester to the other).

If your GUI framework has a common superclass then creating a stress testing application (in a subschema) to drive your application isn't
too difficult. You can drive a form from within code by simulating control events (such as entering text, losing focus, clicking
buttons). You could wrap this up in a simple scripting system so
scripts can be written to drive certain elements of your application.

A nice bonus of doing it this way is that you now effectively have an automated regression testing system. You could compare expected values
on forms with actual values and see if you get what you expect.

Regards,
Allistar. ------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------