----------------------------------------------------------------- Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com ----------------------------------------------------------------- > > -----Original Message----- > > From: Brekke, Jeff [mailto:[EMAIL PROTECTED]] > > Sent: 22 December 2001 19:37 > > To: 'Vincent Massol ' > > Subject: RE: Cactus testing with a framework such as Turbine > > > > > > We've tested our Turbine actions using mocks. I've started using > EasyMock > > since it is faster to get started with than writing all the mock > objects > > up > > front. I did run into some trouble with mocking the IntakeTool that > is in > > the context, but both RunData and Conext are interfaces, so > mocking is > > quite > > simple. This really then just tests your action code only > and nothing > > else. > > Now we've also had to start Turbine in standalone mode in certain > cases > > along with mock objects. So our setup for testing actions/screens: > > > > Setup your mocks of RunData, Context, ParameterParser, etc. > > > > Create an instance of your actions and call the doXXX method > > > > Verify your mocks. > > > > -----Original Message----- > > From: Vincent Massol > > To: 'Cactus Users List' > > Sent: 12/22/01 1:56 AM > > Subject: RE: Cactus testing with a framework such as Turbine > > > > Hi Warner, > > > > I have never used Turbine so I probably won't be of good help ... I > can > > explain the principle but I don't know if it is easy to > apply or not. > > The idea is that you look at the method you want to test > and find out > > what you need to initialize beforehand. The format is : > > > > <inits> > > > > MyClassToTest object = new MyClassToTest(); > > Object.methodToTest(...); > > > > <asserts> > > > > Thus, if in methodToTest() you need a Context object, you'll need to > > create one in the <inits> section. Cactus will be able to > provide the > > standard Servlet API objects to your code > (HttpServletRequest, ...) so > > you don't have to create these, you can use them directly. However, > > Cactus does not provide any Turbine or Velocity objects so > you'll need > > to find a way to create them yourself. > > > > Basically there are 2 strategies : > > - create mock implementations of them, > > - instantiate real objects > > > > The idea of Cactus is to provide integration unit test, so it is > better > > if you succeed in instantiating the real objects. If you go on the > mock > > objects route (www.mockobjects.com), you'll have to decide > whether you > > still want to use Cactus or simply use JUnit and use the > mock servlet > > api implementation from www.mockobjects.com for example. > > > > Hope it helps a bit. > > -Vincent > > > > P.S. : You can have a look at the StrutsTestCase project which lets > you > > unit test Struts actions on top of Cactus. URL = > > http://strutstestcase.sourceforge.net/ > > > > > -----Original Message----- > > > From: Warner Onstine [mailto:[EMAIL PROTECTED]] > > > Sent: 22 December 2001 04:11 > > > To: [EMAIL PROTECTED] > > > Subject: Cactus testing with a framework such as Turbine > > > > > > Hi all, > > > I have been searching for good documentation or examples regarding > > testing > > > a > > > Turbine/Velocity application with Cactus. I just bought the > wonderful > > book > > > Java tools for extreme programming (thanks Nick!), but I am still > > > struggling > > > with what needs to be done in order to test my classes. > > > > > > For those not familiar with Turbine here is a simple setup: > > > 1. Turbine is the servlet that all requests go through. > > > 2. It uses an properties file to start up its various services > (which > > as > > > an > > > app framework it relies on) such as Velocity, Intake, PoolService > > > (database > > > is what I rely on here) > > > 3. Whenever a doGet or doPost is performed it either creates or > looks > > for > > > a > > > RunData instance > > > 4. This instance of RunData gets passed to various classes which I > > want to > > > test as well as a Context (this is defined in my case by the > Velocity > > > service) > > > 5. A lot of things are passed into the context that I > need access to > > such > > > as > > > the Intake service instance. > > > > > > So, given all of this what is my best approach? I don't > want to test > > > Turbine > > > I just want to test my application in relation to Turbine (granted > if > > > there > > > are problems with the framework I will be testing Turbine =). > > > > > > I did search the archives for this, but didn't find > anything in user > > (did > > > find mention of turbine in v2 mail about a month ago). Do > I need to > > wait > > > for > > > v2 (need help on the Turbine part?). > > > > > > -warner > > > > > > +warner onstine+ > > > > > > > > > -- > > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
