I do plan, at some point to use something like httpunit to test the web functionality. However, I was looking to test from the layer boundary back since that is a major integration point of unlike technologies. What would be ideal would be a mechanism to test each layer independently and then collectively. This would allow for checking things like the validators and checking the actual html forms and javascript independent of one another. So, in my case for a particular vertical feature (use case) I would have a test to: - test the html/javascript (done with httpunit or a similar package) - test the xwork.xml routing and calling logic (appropriate return codes and results exist) - test the validator logic (both declarative and programmatic) - test that the interceptors are doing the right thing - test the action execution logic - test the hibernate schema - test the database pooling - test the integration of these individual units
Of course, the nice thing would to be able to do this with little code. :) Anyway, all that I accomplished with my little framework was to test from the xwork.xml back as one functional test. The rest still needs some thought. At the very least, documentation of an approach would make a great addition to the wiki. A more complete solution, would provide a testing framework, which encapsulates the complexities involved in some of these unit tests, to make the effort for a newbie less (subsequently leading to higher adoption, imho). I am just not sure a complete testing solution where dynamic proxies are used and dynamic routing with metadata are used that it is not terribly simple to make testing simple. :) LES -----Original Message----- From: James Cook [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] WebWork Getting Started Guide > I agree with what you are saying, it should be kept pure. However, from > a practical aspect I am looking to test my actions, the stuff they call, > and the many descriptors (validators, xwork.xml, etc) that I have setup. We are considering the following approach to testing. Like you, testing the action feels like we are testing only half of the application. We anticipate using one of the many Http client classes to simulate a browser. (see http://jakarta.apache.org/commons/httpclient/testwebapp.html or http://httpunit.sourceforge.net/) Using this client, we will provide an alternate webwork.xml file that points to special versions of our views. These alternate views are responsible for exercising the actions in much the same way as a real client. The view will only return content if one of these tests fail. Therefore, if the HttpClient detects a content length, then it knows the test has failed. The content returned from a failed test will be HTML information describing the test jim ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
