Hi Alexander,

> -----Original Message-----
> From: Alexander Ananiev [mailto:[EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]>
> To: "Cactus Users List" <[EMAIL PROTECTED]>
> Sent: Sunday, November 23, 2003 7:03 PM
> Subject: Re: Asking Questions
> 
> 
> > Vincent Massol wrote:
> >
> > > Hi JB,
> > >
> > >
> > >>-----Original Message-----
> > >>From: J. B. Rainsberger [mailto:[EMAIL PROTECTED]
> > >>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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to