>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.
Alexander http://www.mockejb.org EJBs made easy ----- 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]
