No one has replied to this message that I posted 10 days ago. Let's broaden the subject...
Is there a place (document, thread) that describes how unit testing is achieved in the Avalon suite ? I have seen a few junit tests but they seemed complex to me and seemed to require quite a setup of environment. Do you guys know about mock objects testing (http://www.mockobjects.com) ? It would seem very well adapted to write unit tests for components. I have included in my previous post on this subject an example of unit test for a JdbcDataAcess component written using Avalon, as an example. I think it would be nice to have such a unit test suite for each component provided in excalibur. Thoughts ? Thanks -Vincent ----- Original Message ----- From: "Vincent Massol" <[EMAIL PROTECTED]> To: "Avalon Developers List" <avalon-dev@jakarta.apache.org> Sent: Tuesday, November 20, 2001 12:21 PM Subject: Re: Automated testing for Phoenix - how? > There is a very easy solution : use mock objects strategy. > > I was about to finish tuning an example on how to use Avalon with J2EE. It > also shows how to unit test your components using mock objects. I'm > attaching it as a draft to show how to perform unit testing using mock > objects. Feel free to ask me if you have any question. > > Thanks > -Vincent > > P.S: I am sorry but no, I don't have enough time right now to help write > unit tests for phoenix ... (already struggling with other projects :) ) > > ----- Original Message ----- > From: "Peter Donald" <[EMAIL PROTECTED]> > To: "Avalon Development" <avalon-dev@jakarta.apache.org> > Sent: Tuesday, November 20, 2001 11:48 AM > Subject: Automated testing for Phoenix - how? > > > > Hi, > > > > I am wondering if anyone has any thoughts on how to best to do automated > > testing for Phoenix. > > > > This recent logger bug is something that should have never happened IMHO > and > > wouldn't have happened if we had had good unit tests in place. In this > > particular case I can think of a way to put in unit tests. > > > > However there is a whole section of Phoenix I find it difficult to think > > about testing. For instance, > > > > 1. how do you test whether Phoenix calls the lifecycle methods in the > correct > > order. > > 2. how do you test that the ConfigurationRepository returns correct > results. > > etc. > > > > The above 2 cases are the two types of situation we could face. In the > first > > we start the container and the container is invoking methods (effectively > in > > control of thread). In the second case we can set up component and then > > invoke it (ie we are in control of thread). > > > > In the case of situations like (2) we could create fake/mock objects and > > configure the component with them. We could then invoke it's methods and > make > > sure it produces desired results. > > > > In the case of situations like (1) it is considerably harder. The only > thing > > I can think of is that we create a fake set of Blocks or whatever. When > ever > > a method was invoked on these Blocks the Block would record the fact and > the > > parameters in a file. After the container is shutdown we would reopen the > > file and make sure the calls were in correct order and that the calls had > the > > correct parameters. > > > > Can anyone think of a better method of doing testing? And does anyone want > to > > volunteer to start of the Unit tests ? ;) > > > > -- > > Cheers, > > > > Pete > > > > --------------------------------------- > > Be nice to your friends. If it weren't > > for them, you'd be a complete stranger. > > --------------------------------------- > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > ---------------------------------------------------------------------------- ---- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
