On 1/16/06, Alexandre Poitras <[EMAIL PROTECTED]> 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
