Unit testing strategy for Avalon (was Re: Automated testing for Phoenix - how?)

[Vincent Massol <vm...@octo.com>]

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" <vm...@octo.com>
To: "Avalon Developers List" <av...@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" <pe...@apache.org>
> To: "Avalon Development" <av...@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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Unit testing strategy for Avalon (was Re: Automated testing for Phoenix - how?)

[Peter Donald <pe...@apache.org>]

On Fri, 30 Nov 2001 01:27, Vincent Massol wrote:
> No one has replied to this message that I posted  10 days ago. Let's
> broaden the subject...

I agree with your idea but haven't had time to implement any ;)

> Is there a place (document, thread) that describes how unit testing is
> achieved in the Avalon suite ? 

Theres a basic JUnit testcase in excalibur ... I haven't actually used it sop 
you may want to ask Giacomo or Berin about it ;)

> 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) ?

>From what I can tell the current Unit testing base class actually provides 
real objects by default for the Configuration/Parameters/Logger objects. It 
will also allow you to overide certain methods if you want to return mock 
objects instead. IIRC you overide 

Foo createFoo()

to overide the Foo stage (where foo may be logger, ComponentManager, COntext 
etc). And thus could return mock objects there. You would then need to add 
some test cases to check whatever you are testing. 

> 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.

yep. Any volunteers? ;)

-- 
Cheers,

Pete

----------------------------------------
Whatever you do will be insignificant, 
but it is very important that you do it. 
                              --Gandhi
----------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>