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" <[EMAIL PROTECTED]> To: "'Cactus Users List'" <[EMAIL PROTECTED]> Sent: Monday, November 24, 2003 1:43 AM Subject: RE: Asking Questions > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
