[shale] testing

[Alexandre Poitras <al...@gmail.com>]

Hi,

I am trying to create tests for my application and I am a little bit
confused. If I use a dynamic mock objects library like EasyMocks, do I
need to use the Shale test package?
Any downsides to using dynamic mock objects instead of static ones? I
have searched around using Google but I couldn't find anything. So I
hope there are some unit testing zealots around here.

Thank for your answers

--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [shale] testing

[Craig McClanahan <cr...@apache.org>]

On 1/16/06, Alexandre Poitras <al...@gmail.com> wrote:
>
> Yeah of course :)
> In the last months I have a number of projects using jMock or easymock
> so I decided to give them a try to see if they are good tool.
> On http://www.mockobjects.com/ web site, they were saying that in TDD
> terminology, stubs were just basically fake objects allowing you to
> run your tests without having to interact with a container or external
> systems. No problem there, that how I always taugh of Mock objects.But
> then they went on saying mock objects are a way to verify the
> interactions between the tested objects and the other application
> objects and you can do this quite easily with easymock.
>
> I was quite confused. Do I need to use a test framework like jMock or
> easymock? Why every frameworks, like Shale, now have test projects if
> some test frameworks allow you to build your mock objects dynamically?
>
> But just after that I stumbled upon a great article on Martin Fowler
> site that I think answered my questions.
> http://www.martinfowler.com/articles/mocksArentStubs.html
> From what I get you can use the traditionnal state based testing
> approach or the new one based on object behavior with the other
> objects. So basically it answered my question but I am putting it here
> in case some people have the same concerns.
>
> From what I see Shale developpers seem to prefer using the
> traditionnal approach and not using those frameworks. Well I was
> wondering if you had any experience with them or any toughts. I see
> several projects using them. I guess for the moment I will stick with
> the traditional approach and use Shale test package but if some people
> had experience with them and Shale test package I would like to hear
> your experience.


In terms of Fowler's descriptions (thanks for the pointer!) I am definitely
in the state-based testing camp.  It's always seemed a bit more natural, but
there's definitely some personal preference issues there.  And I haven't
felt the need for any other mock libraries, either ... what you see in the
Shale source repository is all of what I use for automated testing.

Given that, the Shale test framework is not really just a bunch of stubs ...
because I use it to test the core Shale implementation (as well as for
application level testing), I need a fairly convincing simulation of what
the runtime container will actually do.  For example, I needed the
MockServletContext.getResource() and MockServletContext.getResourcePaths()
methods to actually work, in order to test parts of Shale that scan the web
application's document tree for interesting things.  Likewise, I needed a
simple subset of value binding and expression binding evaluation to actually
work, to test out some of the functionality that requires it.  Providing the
testing framework along with Shale lets me ensure that I can have an
implementation of everything I need, without the potential need to wait for
a third party mock library to implement and release it.

That being said, there still are a bunch of "throws
UnsupportedOperationException()" method implementations -- in other words,
stubbed out methods.  I've been taking the path of implementing the
simulated functionality as I've needed it, or as someone else has needed it,
and I see no change in that policy.  Indeed, someone submitted a patch just
last week to create implementations of MockServletContext.log() and
ExternalContext.encodeNamespace() because they needed those things to work
... and I was happy to apply the patch.  It'll end up helping me too :-).

Thank! Sorry for the long post :)


Craig

Re: [shale] testing

[Alexandre Poitras <al...@gmail.com>]

Yeah of course :)
In the last months I have a number of projects using jMock or easymock
so I decided to give them a try to see if they are good tool.
On http://www.mockobjects.com/ web site, they were saying that in TDD
terminology, stubs were just basically fake objects allowing you to
run your tests without having to interact with a container or external
systems. No problem there, that how I always taugh of Mock objects.But
then they went on saying mock objects are a way to verify the
interactions between the tested objects and the other application
objects and you can do this quite easily with easymock.

I was quite confused. Do I need to use a test framework like jMock or
easymock? Why every frameworks, like Shale, now have test projects if
some test frameworks allow you to build your mock objects dynamically?

But just after that I stumbled upon a great article on Martin Fowler
site that I think answered my questions.
http://www.martinfowler.com/articles/mocksArentStubs.html
>From what I get you can use the traditionnal state based testing
approach or the new one based on object behavior with the other
objects. So basically it answered my question but I am putting it here
in case some people have the same concerns.

>From what I see Shale developpers seem to prefer using the
traditionnal approach and not using those frameworks. Well I was
wondering if you had any experience with them or any toughts. I see
several projects using them. I guess for the moment I will stick with
the traditional approach and use Shale test package but if some people
had experience with them and Shale test package I would like to hear
your experience.

Thank! Sorry for the long post :)

On 1/16/
06, Craig McClanahan <cr...@apache.org> wrote:
> On 1/16/06, Alexandre Poitras <al...@gmail.com> wrote:
> >
> > Ok I'm coming back after having done some reading. From what I
> > understand it's seem the shale test framework provides you stub
> > objects but they aren't true mock objects as in EasyMock or jMocks. Am
> > I correct?
>
>
> Can you be a little more specific on your terminology?  What do you see as
> the differences between "stub" and "true" mock objects?
>
> Craig
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [shale] testing

[Craig McClanahan <cr...@apache.org>]

On 1/16/06, Alexandre Poitras <al...@gmail.com> wrote:
>
> Ok I'm coming back after having done some reading. From what I
> understand it's seem the shale test framework provides you stub
> objects but they aren't true mock objects as in EasyMock or jMocks. Am
> I correct?


Can you be a little more specific on your terminology?  What do you see as
the differences between "stub" and "true" mock objects?

Craig

Re: [shale] testing

[Alexandre Poitras <al...@gmail.com>]

Ok I'm coming back after having done some reading. From what I
understand it's seem the shale test framework provides you stub
objects but they aren't true mock objects as in EasyMock or jMocks. Am
I correct?

On 1/16/06, Alexandre Poitras <al...@gmail.com> wrote:
> Hi,
>
> I am trying to create tests for my application and I am a little bit
> confused. If I use a dynamic mock objects library like EasyMocks, do I
> need to use the Shale test package?
> Any downsides to using dynamic mock objects instead of static ones? I
> have searched around using Google but I couldn't find anything. So I
> hope there are some unit testing zealots around here.
>
> Thank for your answers
>
> --
> Alexandre Poitras
> Québec, Canada
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org