I'm curious to know how other people on the list unit test their Actions. Patrick, at least, uses his custom AbstractActionTest to run the tests (ultimately) via the GenericDispatcher. Others, such as Joe (according to his blog) prefer to treat their Actions as normal classes, with methods that need to be tested after being setup in a certain way.

I can see the attractions of both ways: following one route, you can rely on the framework being used in precisely the same way as it will during deployment. The other way requires a certain amount of knowledge of how the Action will be called, but allows one to pass in state and supporting classes more easily (for example, Mocks to stub out database access)

After having a play with both, I'm tempted to fall to the side of testing each of the methods in turn. This is partly because testing within webwork slows my tests enough to be irksome on my relatively humble machine, and partly because I want to test that each method works as it should --- I can manipulate the tests (eg. causing an IOException, or throwing a database exception) a lot more easily by passing in state and running the method being tested directly than I can by going through the entire framework. If I well off track here, then it'd be nice to get some pointers from the experts....

Regards,

Simon



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to