I think that what you are suggesting is a better approach. Though, having not used mock before, I need to spend some time figuring it out -- especially figuring out how to make it transparent. In my case, I think this may be a challenge because I have Hibernate references in my actions. So, I have to fool hibernate into searching mock stuff and not a db. Hopefully, those guys have some examples of how to do that.
Anyway, I still think this is a little difficult for a newbie to figure out. So, it may be worth either a small framework or at least a wiki entry to explain how to do it and give examples. Of course, that falls in line with the general need for docs...but you guys haven't heard that enough have you?? :) I'll let you know what I end up with. Maybe I'll write that wiki entry in all of my spare time. :) I appreciate the help. LES -----Original Message----- From: Jason Carreira [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 9:55 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] WebWork Getting Started Guide > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > -- > I actually want to move to mockobjects, however I have not > had the time yet to figure out how to use them seemlessly in > leu of Hibernate. Essentially, I would like to find a way to > make the substitution of mock object a runtime option that > the tests, themselves can invoke. I think I have read of a > way, but my schedule is too tight right now. If I do this, > they do become unit tests. However, as is, my tests are > testing both action, any middleware, and the hibernate > mappings. So, in the current incarnation they are somewhat > functional. Obviously, I would like to move to a setup where > I have individual unit tests at the layers and then combine > them into a functional test for interfacing work. If you > have examples or suggestions, I would love to see them. > -- Check out some of the stuff in Xwork / WW2... There's some mock objects tests in there. > 2) Don't use ServletContext and the other web framework > artifacts unless you HAVE to. > -- > The problem that I ran into is that I am not just testing the > action code (i.e. calling action.doExecute). Instead, I am > using the ActionProxy. As a result, I am testing the > xwork.xml file as well. What this means is that if I have an > action declared that, based on the resultCode, uses the > ServletDispatcher then I will hit this ServletContext > problem. I would love to find away of testing this in a way > that would prevent me from hitting that. I would also love > to find a way to incorporate multiple actions in a test is > there is chaining involved. Maybe there is a way to isolate > this more and to interact more intelligently, but I haven't > found it yet. Again, I would love some suggestions as to how > to keep the tests complete (testing the xwork.xml file as > well as the actual execution) and prevent those tests from > succumbing to issues related to the interceptors and result > handlers I have defined. Well, you can mock the ServletContext, etc. too.... > -- > A) it makes it harder to test (only a little with MockObjects, but > still) and > B) Maybe I'm just a purist, but I don't like to muddy my > Actions with web code. I like to have the flexibility to have > them called from a JMSDispatcher, etc. > WebWork2 does a pretty good job of isolating you from the Web > stuff if you only need the parameters, Session, etc. > -- > 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. The best way > I can find to do this is to write my tests to behave as if > they are calling from the web (ActionProxy). The problem is > that I am not calling from the web. So, I have to deal with > the consequences of not having some correct objects. Maybe > it would be better to figure out a way to test all of these > pieces individually, but I simply have not figured out how to > do that yet. So, I suppose the ultimate question is how > should I be writing test cases that test the interceptors, > the validators, the actions, and the xwork.xml file > independantly (for unit > tests) and then together (for use case level functional tests)?? > -- > Thanx, > LES > I would suggest a couple of levels of testing. 1) Unit tests - you set the params into the Action instance and run it. No ActionProxy. Set up mock objects for any external resources the Action uses. 2) Integration tests - test using the ActionProxy to test the xwork.xml file and interceptor configs. Use mocks to isolate the framework from the rest of the system. If you find you need it, you can add a 3rd level using Cactus to run the Actions in the container, or possibly use one of the frameworks that checks the web output. Jason ------------------------------------------------------- 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
