jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: MockEJB (was:Re: Asking Questions)
Date Wed, 26 Nov 2003 10:39:21 GMT


> -----Original Message-----
> From: Alexander Ananiev [mailto:alexander@myarch.com]
> Sent: 26 November 2003 05:20
> To: Cactus Users List
> Subject: Re: MockEJB (was:Re: Asking Questions)
> 
> Well, it's hardly a feat. My class (OptionalCactusTestCase) extends
> ServletTestCase and overrides runBare of JUnit TestCase. So on the
server
> ( when ServletTestCase's request object is not null) it simply calls
> "super"
> to let ServletTestCase handle it, otherwise it runs the class locally.
> Delegation to "super" is controlled by the system property,
alternatively
> there is a switch method one can override.
> I wanted to do something more elegant using Cactus' Suites,
unfortunately
> too many people are still on Cactus 1.4 so I'll probably tackle it in
the
> next release.
> 

Cool. So, if it's running in "offline" mode you're setting automatically
the implicit objects with mocks? This is nice. It's what I imagined to
do some time ago for Cactus
(http://www.mail-archive.com/cactus-dev@jakarta.apache.org/msg01423.html
) but I've never come to do it for lack of time... ;-)

> MockEJB nightly build with docs and examples is available here:
> http://www.myarch.com/mockejb.
> 
> My point about AOP was that with mock objects one can easily implement
a
> home-grown interceptor framework and use that for testing ( I did just
> that
> in MockEJB). Or, for example, I use  mock UserTransaction from
> "mockrunner"
> (http://mockrunner.sourceforge.net/) to make sure that my code commits
or
> rollbacks correctly. This, of course, makes test classes not directly
> portable to the container environment, so I had a bunch of "ifs" to
turn
> certain tests on or off depending of where they run. Keeping pure
> "offline"
> code in a different class might be cleaner, but I think it's more
natural
> to
> develop tests around business logic than based on where they run.

I think I understand what you mean. Bascially you're saying that
anything that is used to run offline only should be put in a different
place (like in an aspect) so that it can be turned on or off depending
whether you're running in "online" or "offline" mode?

I agree this is the main problem with tests being reused both for
offline/online. One other solution is to ignore offline behavior
setters. But none of these solutions is completely satisfactory.

Actually I brought this subject in 2001 and at that time I had decided
to drop it as in practice I thought it would lead to different tests and
you would never want to run the same test both in offline and online
modes. I'm not sure anymore but trying it is the best way to know... ;-)

Thanks
-Vincent

> 
> Thanks,
> Alexander
> 
> http://www.mockejb.org
> EJBs made easy
> 
> ----- Original Message -----
> From: "Vincent Massol" <vmassol@pivolis.com>
> To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
> Sent: Tuesday, November 25, 2003 1:50 AM
> Subject: RE: MockEJB (was:Re: Asking Questions)
> 
> 
> > Hi Alexander,
> >
> > That looks cool. We had discussed this feature some time ago on this
> > list about the ability to run cactus tests "offline" and "online" at
a
> > flick of a switch. I'm curious to know how you'll perform this feat.
Is
> > there any mail/doc/etc about it?
> >
> > I don't understand your point about UserTransaction or JMS
> > TopicPublisher requiring AOP to be able to test code using them.
Could
> > you post a simple example of a method to test that we wouldn't be
able
> > to test without AOP?
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Alexander Ananiev [mailto:alexander@myarch.com]
> > > Sent: 25 November 2003 05:24
> > > To: Cactus Users List
> > > Subject: MockEJB (was:Re: Asking Questions)
> > >
> > > Hi Vincent,
> > >
> > > The upcoming release of MockEJB will indeed be integrated with
Cactus.
> > It
> > > simply means that any MockEJB test can also run as the Cactus test
> > with a
> > > "flick of a switch", e.g. by changing a system property. So the
idea
> > is
> > > that
> > > developers routinely run the test class outside of the container
for
> > speed
> > > and convenience and then before commit they would run the same
test
> > class
> > > in
> > > the container using Cactus to verify the correctness of the code
(and
> > > deployment descriptors) in the "non-mock" environment.
> > > At the same time, even inside the container, mock EJBs  can still
be
> > > deployed to isolate the EJBs under test from the rest of the
> > application.
> > > This sounds good in theory, however in reality many tests simply
> > cannot be
> > > executed inside the container since most of J2EE system classes
are
> > almost
> > > untestable. E.g., I can very easily come up with mock
UserTransaction
> > or
> > > JMS
> > > TopicPublisher and check what methods were called and what
parameters
> > were
> > > passed. The only way to do it with the container-provided classes
is
> > to
> > > use
> > > AOP.
> > > So I wonder how people deal with this problem in the real world...
> > >
> > > Thanks,
> > >
> > > Alexander
> > >
> > > http://www.mockejb.org
> > > EJBs made easy
> > >
> > > ----- Original Message -----
> > > From: "Vincent Massol" <vmassol@pivolis.com>
> > > To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
> > > Sent: Monday, November 24, 2003 1:43 AM
> > > Subject: RE: Asking Questions
> > >
> > >
> > > > Hi Alexander,
> > > >
> > > > > -----Original Message-----
> > > > > From: Alexander Ananiev [mailto:alexander@myarch.com]
> > > > > Sent: 24 November 2003 01:56
> > > > > To: Cactus Users List
> > > > > Subject: Re: Asking Questions
> > > > >
> > > > > From what I understand, Cactus simply provides the capability
for
> > > > testing
> > > > > inside the container and it does not dictate any particular
> > testing
> > > > > methodology. You can use for true unit testing or for
integration
> > > > testing
> > > > > if
> > > > > you so choose; same way plain JUnit class can be used for
> > integration
> > > > > testing. It all depends on the setup code and the logic of
your
> > test.
> > > > > Whether testing deployment descriptors should be part of the
unit
> > test
> > > > > depends on the project organization. Most teams are small
enough
> > so
> > > > > developers are responsible for business logic and deployment
> > > > descriptors.
> > > > > So
> > > > > being able to run the unit test inside the container is simply
a
> > > > matter of
> > > > > convenience, and it is easier than writing the whole new
XMLUnit
> > test
> > > > just
> > > > > to test deployment descriptors.
> > > > > Of course, with the right test setup, developers don't have to
run
> > > > their
> > > > > tests inside the container every time they change the business
> > logic
> > > > but I
> > > > > would say doing it before commit is a good practice.
> > > >
> > > > You've summed it up nicely!
> > > >
> > > > >
> > > > > Alexander
> > > > > http://www.mockejb.org
> > > > > EJBs made easy
> > > >
> > > > I really need to look at your nice mockejb project. I've seem
that
> > > > you've written somewhere about Cactus integration. Let me know
if I
> > can
> > > > help.
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "J. B. Rainsberger" <jbrains@rogers.com>
> > > > > To: "Cactus Users List" <cactus-user@jakarta.apache.org>
> > > > > Sent: Sunday, November 23, 2003 7:03 PM
> > > > > Subject: Re: Asking Questions
> > > > >
> > > > >
> > > > > > Vincent Massol wrote:
> > > > > >
> > > > > > > Hi JB,
> > > > > > >
> > > > > > >
> > > > > > >>-----Original Message-----
> > > > > > >>From: J. B. Rainsberger [mailto:jbrains@rogers.com]
> > > > > > >>Sent: 24 November 2003 00:00
> > > > > > >>To: Cactus Users List
> > > > > > >>Subject: Re: Asking Questions
> > > > > > >>
> > > > > > >>Owen Chau wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >>>Cactus supports "integration unit testing". Can
you
explain
> > > > > > >>>the nature of this "integration" you refer to.
> > > > > > >>
> > > > > > >>Integration Tests exercise multiple objects together.
Object
> > Tests
> > > > > > >>exercise a single object in isolation, usually by faking
its
> > > > > > >>collaborators.
> > > > > > >>
> > > > > > >> > Also, how about the
> > > > > > >>
> > > > > > >>>advantages,
> > > > > > >>>if any, of integration unit testing, as opposed
to
testing
> > the
> > > > unit
> > > > > > >
> > > > > > > in
> > > > > > >
> > > > > > >>>isolation. Do we need any additional tool and/techniques
to
> > cover
> > > > > > >
> > > > > > > the
> > > > > > >
> > > > > > >>>other aspects of unit testing?
> > > > > > >>
> > > > > > >>In theory, if you have 100% Object Test coverage /and/
perfect
> > > > > > >>interface/implementation separation, then Integration
Tests
> > are
> > > > > > >>unnecessary. Since no-one has 100% Object Test coverage
/and/
> > > > perfect
> > > > > > >>interface/implementation separation, Integration Tests
are
> > > > necessary
> > > > > > >
> > > > > > > to
> > > > > > >
> > > > > > >>plug the holes.
> > > > > > >
> > > > > > >
> > > > > > > I don't quite agree! :-) You're only talking about
integration
> > > > between
> > > > > > > components themselves. Where is the integration with the
> > > > > > > container/database/etc tested? All the meta-data files
(config
> > > > files,
> > > > > > > deployment descriptors, etc) do not get tested with object
> > test
> > > > > > > coverage, right?
> > > > > >
> > > > > > Well, I can check the deployment descriptors with XMLUnit. I
> > don't
> > > > test
> > > > > > the container. I don't test the database.
> > > > > >
> > > > > > I have a few classes that interact with the database, and
for
> > that I
> > > > > > have a few Object Tests that use the database. Everything
else
> > uses
> > > > > > those database-aware classes through an interface, so I can
test
> > > > > > business logic against either mocks or an in-memory
"database".
> > > > > >
> > > > > > I have a suite of Deployment Tests, if I need them, that
help me
> > > > deploy
> > > > > > my application correctly: authentication settings,
descriptors,
> > and
> > > > so
> > > > > > on. Those are Object Tests, in a sense: they are isolated
tests.
> > > > > > (Pretend a file on the file system were an object.)
> > > > > >
> > > > > > I think that about covers it. Of course, the End-to-End
Tests
> > verify
> > > > > > that the whole application does something useful. Usually
these
> > are
> > > > > > Customer Tests, but sometimes I write some if I'm worried
about
> > > > whether
> > > > > > I understand what the web page flow needs to be. Usually I
just
> > > > model
> > > > > > those things and test them in isolation.
> > > > > > --
> > > > > > J. B. Rainsberger,
> > > > > > Diaspar Software Services
> > > > > > http://www.diasparsoftware.com :: +1 416 791-8603
> > > > > > Let's write software that people understand
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > cactus-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > cactus-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > cactus-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org



Mime
View raw message