A Snapshot of the Eclipse plug-in!!

NOTE: The GUI capture here is obsolete for a newer version please visit:

http://efekctive.com/picture_library/blogging/devriot-ui-new-linux1.gif

Copyright José Cornado (c) 2005-2006

There are a couple of things to notice, we think:

The user just needs to provide the parameter and expected return values. The rest is optional information: an ID to execute the test in a particular order, pre-conditions and post conditions of the object under examination, number of times to execute, and load/stress level.

The method shown is private, but our technology can still reach it. It is really poweful and dynamic. One of the advantages of this feature is that your QA investment is immune to Refactoring.

As several people have noted over different lists and forums, Refactoring can (and does) make public or protected methods private.

In this case the QA efforts are lost because Junit, or Nunit for that matter, just can not handle the change. What to do? wait and let the code base grow without testing? risk to lose several weeks of QA development? or just do not use refactoring?

Another is the ability of testing even the exceptions (type and contents) thrown by the logic under scrutiny.

Also, this is the same interface that will be used to handle GUI testing. Nothing to capture :-}