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:[EMAIL PROTECTED] > 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" <[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
