All this talk of Jack of all trades using a hammer to turn screws! Its not as if people are suggesting that Cactus be enhanced to provide contact list management or ip routing. Some of my servlet tests require the services of a functional servlet container and so Catcus's in-container nature is very useful. Other of my servlet tests do not want an actual container to perform servlet API methods but instead want to verify that the correct method calls have been made. Cactus can't do this at the moment and so I am forced to look elsewhere or build my own mock servlet API implementation. If Cactus provided a mock servlet API implementation then I would be able to use the same tool for the same job, testing servlets. The fact that Cactus itself would benefit from a mock API for its own unit testing is another indication to me that this would be a sensible route to take. As for having the same tests that can be run in-container or mock I am not convinced. As mentioned above I see some tests as requiring a functional container and some a mock container. Although the production code shouldn't know if a mock implementation is being used the test code certainly must as it needs to set the expected calls on the mock and subsequently validate those calls. I have heard the idea that running the same tests both in-conatiner and mock validates that your container behaves in the same way as the mock , so indicating that tests that work with mock objects will also work in the container in production. If this is the case then it seems that these are container tests, not servlet tests. There seems little point in everyone testing the same servlet containers for compatibility with the mock implementation, perhaps Cactus could be the place where these tests are stored with contributions from servlet container users as required. As Vincent says on the Cactus web site, ultimately it would be good if servlet containers came in a testable form. Maybe if the reference implementation came with a mock api for testing... Who knows, but at the moment Cactus seems to me to be a sensible place for a mock servlet API implementation to live. .../Bob On 13/06/2001 09:00:22 Jon Belinfante wrote: > All this talk of cactus futire direction. > A bit of advice from my wisdom. Make a tool a master of one trade, and not a > jack of many. > From my few days playing with Cactus, it seems very powerful in its narrow field > of testing servlets and JSPs whilst they are deployed in the container. This is > extremely advantageous in its self.. My suggestions is to leave it there, > Perhaps other tools can deploy other techniques. In the same way as a good > carpenter has many high quality tools in the tool box, each specialised for a > task, Software Engineers should follow suit. > > Jon. > > > |--------+-----------------------> > | | "Vincent | > | | Massol" | > | | <vmassol@octo| > | | .com> | > | | | > | | 12/06/01 | > | | 20:12 | > | | Please | > | | respond to | > | | jakarta-commo| > | | ns; Please | > | | respond to | > | | "Vincent | > | | Massol" | > | | | > |--------+-----------------------> > >----------------------------------------------------------------------------| > | | > | To: [EMAIL PROTECTED] | > | cc: (bcc: Jon Belinfante/London/CWB) | > | Subject: [cactus] Summary of Cactus goals/intents (WAS Re: Mock | > | Objects for servlets (was Re: Roadmap for Cactus 1.1)) | > >----------------------------------------------------------------------------| > > > > > > ----- Original Message ----- > From: "Russell Gold" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 12, 2001 4:53 PM > Subject: RE: Mock Objects for servlets (was Re: Roadmap for Cactus 1.1) > > > > At 11:12 AM 6/12/2001 -0400, Steve Salkin wrote: > > > > I have a feeling that I am missing the point here, but it > > > > feels almost as though you have found a hammer you really > > > > like and now wish it could turn screws as well. > > > > > >LOL. But this amusing characterization somewhat dodges the point, > > >which is that Cactus is pretty good at one kind of testing, and > > >would be an even better tool if it could do another kind of > > >testing. > > > > > >As the apparent author explains on the mock objects vs. in container > > >testing page > > > >(<http://jakarta.apache.org/commons/cactus/mockobjects.html>http://jakarta. > apache.org/commons/cactus/mockobjects.html) > > > > > >he is not averse to moving Cactus towards the mock objects strategy > > >precisely because it offers a more comprehensive approach and because > > >it tends to reinforce good design and implementation habits. > > > > > >I personally would like to see both choices available from within > > >one tool, for several reasons: > > > > > >(1) it will increase the userbase and thus the level of improvements > > > made available for this tool; > > >(2) it is more likely to satisfy the disparate needs of developers > > >(3) each mode helps to highlight problems in the other. For example, > > > an in-container test that suceeds while a mock test fails may > > > point out an error in a container-level mock object. > > > > > >I am sure that more reasons can be adduced in favor of this. Against it > > >is the argument of simplicity over complexity and the "one tool for one > > >job" philosophy. > > > > > >I am interested in an amplification of your thoughts about this. > > > > OK, I have in fact implemented something like this in HttpUnit, in an > > alternate package (servletunit) which uses a lot of common code. What I > > found is that the testing strategies of the two approaches (black-box test > > via HTTP and white-box test via mock-objects) seem to be very different. > I > > see some synergy in that where the test involves the examination of the > > resultant HTML, I often want to check the same things, but it seems with > > the limited number of mock-object tests that I have done, that there is > not > > a lot of overlap. > > > > In general I remember the lesson that many engineers learn: the more > > missions a single tool is expected to perform, the harder it is to make it > > good at any one mission. It is only because the two are supported in > > different packages that I feel comfortable even having them in HttpUnit, > > which at least has the unifying philosophy that all tests should be run > > from the command line and involve interpretation of HTML. > > > > Cactus seems to take an entirely different approach, placing its tests in > > the container itself. Now, this leads to a particular approach to testing > > which may not work well in other contexts. While I certainly understand > > and agree with the desire to be able to perform multiple types of testing, > > I don't see why it is important to have them all supported by a single > tool. > > > > It seems to me that users of Cactus are better served by improving its > > in-container abilities to address more kinds of in-container tests than to > > make it do something entirely foreign to its nature. Possibly I am wrong > > about its underlying philosophy? > > > > Wow wow wow .... We're going a bit fast here ... :) > > Here are some facts that represent the current status of Cactus : > > 1 - Cactus is for the moment an in-container unit testing tool that provides > a middle ground between very fine-grained mock object style unit testing and > very coarse grain functional test (like what HttpUnit does) > > 2 - Cactus is dedicated to push to the limit the in-container approach (see > http://jakarta.apache.org/commons/cactus/goals.html) > > 3 - In order to provide additional useful features for Cactus users, I have > brought up several subjects : > > a - adding functional tests API to Cactus. The idea is simply to provide > some API so that output streams can be checked in more powerful method that > just checking against the string representation of the result. These API > would be used in endXXX() test case methods. This proposal seemed to be well > accepted as I have received only positive feedbacks. (Note: This is where I > asked Russell Gold if he would be willing to help and integrate HttpUnit > into Cactus instead of Cactus reinventing the wheel ... He has very rightly > said that he has to look more into Cactus before committing an answer) > > b - think about the interest of bringing Mock Object testing style into > Cactus (when I say "Mock Objects", I refer to the definition described in > http://www.sidewize.com/company/mockobjects.pdf). After reading this paper > and meeting with the authors (Xtc club in London, www.xpdeveloper.com), I > found that they indeed had a very interesting approach that was > complementary in most cases. There are pros and cons of each approach (see > http://jakarta.apache.org/commons/cactus/mockobjects.html for a comparison > of both approaches). Bringing the 2 together might solve the cons of each > ... *However*, I am not sure it is either possible nor desirable. This is > why I have opened the debate, which is still open, about how we could > integrate mock objects into Cactus in a seamless manner as possible ... > Nothing has been committed on that point. It is completely unchartered > territory and fresh ground ... :) > > The goals of a) and b) above are to prevent the user from having to use > several frameworks as much as possible. It is already difficult to convince > Business persons that writing test cases is necessary (except for Acceptance > tests which are easily accepted). Now if you have to explain to them that > the developers have to use 3 frameworks (Mock objects, Cactus, HttpUnit), > that they have to install them and be trained in how to use them, deploy > them, .... then it is harder to justify. But maybe this is the right way to > do it ... ? > > Cactus will continue to progress. If it has any meaning, the ultimate goal > could be to be the tool of choice for testing server side java code ... > (this is my dream at least ... :) ). > > Thanks > Vincent. > > > > > ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
