Hi Zhang, > -----Original Message----- > From: Zhang, Li [mailto:[EMAIL PROTECTED]] > Sent: 20 November 2002 20:39 > To: 'Cactus Users List' > Subject: RE: [Musing] Offline mode > > I really like the idea of writing one test case for both in-container test > and out-of-container test. My only question is how soon I can use it in my > project? I just can't wait. :)
Glad you like it! The answer is: as soon as someone starts participating :-) -Vincent > > Thanks. > > Li > > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 20, 2002 1:16 PM > To: 'Cactus Users List' > Subject: RE: [Musing] Offline mode > > > Hi Jason, > > The idea is simply productivity boost. Running a Cactus test takes time > whereas a mock one is fast. You can run around 400 mock objects tests in > a second whereas Cactus tests will take at least 10-20 seconds overall > (or more. That's best time). Cactus tests yields more value as they > really verify that it works. But MO tests are enough to find errors not > related to integration. Both are good and complementary. > > The idea is to have the best of both worlds by writing only one test (if > possible, not sure yet how well this would be). That is you would run > the tests quickly from your IDE as you type and from time to time you > would run with online mode on to verify it does really work. > > In practice I am using both MO and Cactus on my projects but I have to > write against 2 frameworks. > > Does it make sense? > > Thanks > -Vincent > > > -----Original Message----- > > From: Robertson, Jason [mailto:[EMAIL PROTECTED]] > > Sent: 20 November 2002 18:35 > > To: 'Cactus Users List' > > Subject: RE: [Musing] Offline mode > > > > Sorry to take so long to respond, but I'm not clear as to the full > > benefits > > of doing this. If I'm creating a servlet, and that servlet does > nothing > > involving certain container resources (i.e., connection pools, EJBs, > > etc.), > > then I could see how a "mock" container could work. But how often does > > this > > happen? > > > > And I don't see at all how it could test JSPs (would the mock > container > > compile them into servlets?), or EJBs. > > > > The far majority of my cactus testing is testing EJBs, and will soon > be > > testing Struts action classes which will all use EJBs to get their > data. > > Am > > I just not a potential "offline mode" user, and that's why I can't see > it? > > Am I missing the big picture? > > > > Jason > > > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, November 02, 2002 12:00 PM > > To: 'Cactus Users List' > > Cc: [EMAIL PROTECTED] > > Subject: [Musing] Offline mode > > > > > > Hi Cactusers, > > > > Today I haven been thinking about Cactus and Mock Objects and more > > specifically when to choose one over another, etc. The choice is not > > always easy. In the past, I had thought about implementing an offline > > mode in Cactus, i.e. the ability to run the same cactus test without a > > container. Of course, it won't be integration unit testing any more > but > > the rationale is the following: > > > > * use the offline mode when coding in your favorite IDE. Run the tests > > very often. > > * use the online mode to perform integration unit testing with your > > target containers. > > * The benefits over using an existing mock object library for > > Servlet/JSP/Filter/EJBs API is evident: tests written using the Cactus > > API can run "as is" in in-container mode. > > > > Of course, not all tests should be run in both modes but a lot of them > > could. > > > > At that time I had dismissed the idea because I did not see how I > could > > do it and I did not see the real interest of doing so. It seems much > > clearer now... :-) > > > > Here are some ideas: > > > > * The mode is specified by passing a JVM system parameter > > (-Dcactus.offline=true) > > * In offline mode, Cactus creates dummy (mock) Servlet implicit > objects, > > and filling them with the information it has (mostly from WebRequest). > > * In addition, the wrappers need to be extended (or added) to offer > > methods to set the behaviours of the mocks. For example: > > HttpServletRequestWrapper.setForwardResult(HttpServletResponse > response, > > OutputStream mockStream) > > * In online mode, the setForwardResult() and such can be ignored. > > However, if we want to refine this, we can also have an additional > > HttpServletRequestWrapper.setForwardResult(HttpServletResponse > response, > > OutputStream mockStream, boolean useInOnlineMode) API that tells > Cactus > > to use this even in online mode. This can be handy when the JSP is not > > yet written and you still wish to perform integration unit tests. > > * In offline mode, there is no HTTP connection to the server side and > > beginXXX(), testXXX() and endXXX() are all run on the client side. > > > > What do you think? > > > > -Vincent > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:cactus-user- > > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:cactus-user- > > [EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-user- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
