I have chosen to test actions by substituting another views.properties file.
This "testing_view.properties" file includes the same type of calls the
normal view would execute, however the results of these views produce an XML
stream based on their outcome.
<testcase>
<test name="doUpdate">
<result type="success">Success</result>
</test>
<test name="doUpdate">
<result type="failure">SQLException: MANAGER_ID invalid column
name</result>
</test>
</testcase>
The unit test is kicked off using a normal JUnit testcase, using HttpUnit as
the communication device. I find that this approach tests the actual
web-tier more effectively than testing the actions directly. This is because
the process of parsing the query string and returning a web-tier result is
still exercised.
jim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:opensymphony-webwork-admin@;lists.sourceforge.net]On Behalf Of
> Simon Stewart
> Sent: Thursday, November 07, 2002 8:01 AM
> To: [EMAIL PROTECTED]
> Subject: [OS-webwork] Unit testing Actions
>
>
> 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
>
-------------------------------------------------------
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
