headers
Anthony Ikeda | 1 Aug 2007 04:02
Picon

Docs or books on jMock2

I've been looking into introductin jMock2 into our testing processes for server-side classes and was wondering on which books or docs are best at explaining it's use.
 
So far this is what I understand, and please correct me if I'm wrong:
* When creating a mock from the Mockery object, all methods that are expected to be called must be captured through the checking() method as Expectations. For example:
 
Mockery mockery = new Mockery();
HttpServletRequest request = mockery.mock(HttpServletRequest.class);
HttpSession session = mockery.mock(HttpSession.class);

mockery.checking(new Expectations() { {
 allow(request).getParameter("j_username");
 will(returnValue("user"));
 allow(request).getParameter("j_password");
 will(returnValue("pass"));
 allow(request).getSession();
 will(returnValue(session));
}});

Questions:

Is there a wildcard style call that can allow me to ignore all other methods calls or do I need to "ignoring()" them manually?

Is it best practice to be mocking ALL the classes required, for example in a servlet container, or should I be stubbing some of them using say Spring mock classes?

What is the best documentation for understanding the Expectations syntax (this is introducting a new level of Generics for me that I'm new to)?

How do I mock outputstreams so I can read output from classes such as a servlet or JSP?

Thanks,

Anthony

 

Permalink | Reply | 9 comments |
headers
Geoffrey Wiseman | 1 Aug 2007 04:19
Picon
Gravatar

Re: Docs or books on jMock2

On 7/31/07, Anthony Ikeda <anthony.ikeda.cardlink-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

So far this is what I understand, and please correct me if I'm wrong:
* When creating a mock from the Mockery object, all methods that are expected to be called must be captured through the checking() method as Expectations. For example:

Yes; although these can be ignored, allowed, or expected a certain number of times.

Mockery mockery = new Mockery();
HttpServletRequest request = mockery.mock(HttpServletRequest.class);
HttpSession session = mockery.mock(HttpSession.class);

mockery.checking(new Expectations() { {
 allow(request).getParameter("j_username");
 will(returnValue("user"));
 allow(request).getParameter("j_password");
 will(returnValue("pass"));
 allow(request).getSession();
 will(returnValue(session));
}});

Questions:

Is there a wildcard style call that can allow me to ignore all other methods calls or do I need to "ignoring()" them manually?

ignoring(request);
ignoring(session);

This'll ignore everything you didn't expect.  I'd typically use this approach when I don't control the class being mocked and there are a lot of calls.

Is it best practice to be mocking ALL the classes required, for example in a servlet container, or should I be stubbing some of them using say Spring mock classes?

Depends on who you ask; the typical answer from the jMock team would be to mock APIs you control, and not, for instance, the HttpSession, at least, not without providing your own layer that isolates the responsibilities and supplies a fine-grained, mockable interface.  Other people would argue differently.  Certainly, jMock's style is best suited to APIs you control, but I use it outside of that context all the time.

What is the best documentation for understanding the Expectations syntax (this is introducting a new level of Generics for me that I'm new to)?

The Cookbook for 2.0 seems to be pretty good; what are you having troubles with?

How do I mock outputstreams so I can read output from classes such as a servlet or JSP?

I'm not sure I'd bother here; far too many calls to your average output stream, and the content's very specific.  I'd be inclined to use a state-based rather than interaction-based test here, although if that requires in-container testing, I might look at a variety of other approaches.
 
  - Geoffrey
--
Geoffrey Wiseman
Permalink | Reply | 6 comments |
headers
Dale King | 1 Aug 2007 05:33
Picon

Re: Verifying Mockery / Exceptions

I am doing initialization on the super.context object in the <at> Before (setting the Imposteriser in fact), but I am creating it in the declaration. In other words, this is what I have in the superclass:

    protected JUnit4Mockery context = new JUnit4Mockery();

This works by default because the default runner in JUnit 4 (which is the superclass of the JMock one) creates a new instance of the test class for each test that is run. So each test that runs still gets its own context.

This is not guaranteed for runners in general. You could have a runner that only creates one instance of the class for all tests (see http://tech.groups.yahoo.com/group/junit/message/19159 for example).

You could try to work around this possibility or ignore these runners and wait for 2.3.0 at which time it will no longer be a problem once you remove the context variable from the subclass.

Frankly, if you read the javadocs for RunWith (see http://www.junit.org/junit/javadoc/4.3/index.htm) you'll see that it was a late addition and not well thought out and will probably be changing. So I wouldn't get to worked up over other possible runners since 2.3.0 should come out soon.

On 7/31/07, Geoffrey Wiseman <geoffrey.wiseman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On 7/31/07, Dale King < dalewking-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I'm the one that submitted 138 and I didn't find it took that much to work around it. I still do the setup in the superclass using <at> Before in the superclass, I put the <at> RunWith( JMock.class ) on the superclass and I have a JUnit4Mockery member in the superclass that is initialized in the setup.

The only effect of bug 138 is that I have to add this line to the subclasses to expose the context from the superclass:

    public final JUnit4Mockery context = super.context;

You are presumably not initializing super.context in a <at> Before, then, which won't have run by the time the instance tries to grab its super.context?

Trying to decide between putting the super initialization in the variable declaration or moving the child-class initialization to another <at> Before, which'll increase the necessary lines of code per-subclass.  Probably do the former for now, then reverse it after -138.

  - Geoffrey
--
Geoffrey Wiseman



--
Dale King
Permalink | Reply | 0 comments |
headers
Anthony Ikeda | 1 Aug 2007 05:37
Picon

Re: Docs or books on jMock2

Thanks Geoff,
Unfortunately the application I'm writing tests for is a legacy app and there is alot of business logic locked into the servlets so I need to concentrate on the proceses happening there. Se below for more comments:

 
On 7/31/07, Anthony Ikeda < anthony.ikeda.cardlink-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
What is the best documentation for understanding the Expectations syntax (this is introducting a new level of Generics for me that I'm new to)?
The Cookbook for 2.0 seems to be pretty good; what are you having troubles with?
 
Well what I'm having troubles with is the grammer primarily. I've been assuming that the syntax placed betwen the double braces ({{ }}) is processed sequentially. Such that:
 
1|{{
2| allow(request).getParameter("j_username");
3| will(returnValue("user"));
4|
5| allow(request).getParameter("j_password");
6| will(returnValue("pass")); 
7|
8| allow(request).getSession();
9| will(returnValue(session));
0|}}
 
Each paired line above is assumed as a kind of workflow. So lines 2 & 3 belong together, as such, as does 5 & 6 and 8 & 9.
 
Also how do I handle an expectation such as: session.setAttribute("username", name); ?
 
Another last point is, what does the double braces signify? This is something new to me as well.
 
Anthony

 
Permalink | Reply | 5 comments |
headers
Dale King | 1 Aug 2007 06:00
Picon

Re: Discussion of opening up Mockery to let it be subclassed

I've gotten my native imposteriser working with JMock2 using the JMock 1 style expectations.

But it seems to me that it would be possible to refactor the internals of JMock to eliminate the thing that keeps you from also using the invocation style to specify the expectations for the native methods.

The basic problem is the whole CaptureControl interface assumption that the object that the mocked method will be called on (the parameter to the "of" method) is an instance of CaptureControl. While that works for the default imposertiser it does not work for the native imposteriser. For static native methods the parameter is a class and for instance native methods it is just an instance, not in any way connected to CaptureControl.

It seems to me that there are ways to eliminate the whole requirement of having mock instances implement this CaptureControl interface. You know the classes better and how they are isolated from each other, so I'll open the question to you to think about while I dig into deciphering the JMock code.

On 7/19/07, Nat Pryce <nat.pryce-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
jMock 2 still has a jmock-1-alike way of specifying expectations
without calling methods.  If you use a Matcher (that matches one or
more mock objects) instead of directly using a mock object you get
given back an interface with chained methods that let you use Matchers
to specify the method and arguments.

That might work as a plugin-point for what you're trying to achieve.

--Nat

On 19/07/07, Dale King <dalewking-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
> After having more time to think about it I realized that Imposterizer is
> only the tip of the iceberg. I think that actually isn't a real problem as I
> can create an imposterizer that says redirect all native method calls static
> or instance to the given Invokable.
>
> The whole new way of expressing expectations is not really compatible with
> native methods.
>
> First off the assumption that you execute the method you want to mock to set
> expectations doesn't really work. The static methods are very likely private
> and it may not be possible/convenient to actually invoke the method for
> setting the expectation. This was not a problem with JMock 1 because all you
> had to do to add expectations was give the name of the method.
>
> The whole CaptureControl thing and the way expectations are built assumes
> that you have an instance. That really doesn't work with static methods. It
> also doesn't work for instance methods as I can't make the instance
> implement CaptureControl.
>
> I want to make it work in the JMock 2 framework, butI think what I will have
> to create some new classes and cannot rely as heavily on the existing stuff.
> I will probably have to create a different method for expressing the
> expectations that is more JMock 1 like using method names instead of relying
> on the pattern of invoking the method.
>
> I've got some more studying and work to do.
>
>
> On 7/19/07, Nat Pryce <nat.pryce-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > I don't want to open up the internals of jMock 2.  jMock 1 was *too*
> > open and that made it hard to add new features without breaking
> > backward compatability, which meant that new features didn't get into
> > the library.
> >
> > jMock 2 has a set of supported extension points defined in terms of
> > interfaces and methods that accept those interfaces.
> >
> > To make jMock2 support your use case we'd need to understand what
> > extension points it needs.  What do you need to mock native methods
> > beyond what the Imposteriser provides?
> >
> > --Nat
> >
> > On 19/07/07, Dale King < dalewking-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > A while back I developed (but never released) an extension for JMock 1
> that
> > > gave you the ability to extend mocking to native methods. I started
> looking
> > > at moving it to JMock 2 but it doesn't look like there is any good way
> to do
> > > it because much of the functionality in Mockery is private.
> > >
> > > Mocking native methods is a bit different from mocking interfaces.
> > >
> > > First you can mock static native methods in which case you really aren't
> > > creating an instance you are saying all static native methods for a
> given
> > > class should be routed to a given InvocationHandler.
> > >
> > > You can also mock instance native methods. In this case again you are
> not
> > > creating a object instance. Instead you want to pass in an instance to
> mock
> > > the native methods of.
> > >
> > > The problem is that these don't quite fit into the model of Imposterizer
> and
> > > the mock method of Mockery. You could sort of squeeze mocking of static
> > > native methods into that mold, but mocking instance native methods does
> not
> > > work due to the need to pass an instance to mock the native methods of.
> > >
> > >  I already have all the working code to handle registering for native
> method
> > > calls to be redirected to a particular InvocationHandler. The hard part
> is
> > > trying to fit this into JMock which is designed under the model of
> mocking
> > > means creating a new object instance.
> > >
> > > My first thought was to subclass Mockery to add a new methods
> > >
> > >    <T> void mockNative( T instanceOrClass );
> > >     <T> void mockNative( T instanceOrClass, String name );
> > >
> > > If you pass a Class object to the method it says to mock the static
> native
> > > methods. If you pass anything else (other than null) it says to mock the
> > > instance native methods of that instance.
> > >
> > > But I find that much of the guts of Mockery was made private which
> prevents
> > > any useful subclassing. I think that if Mockery.MockObject were exposed
> that
> > > would be enough to allow me to do what I want to do without having to
> > > duplicate the existing Mockery class.
> > >
> > > Or perhaps there is another way to better accomplish what I want to do.
> > >
> > > For reference in JMock 1 what I did was create a different CoreMock
> class
> > > and my own subclass of MockObjectTestCase as follows:
> > >
> > >  abstract public class JniMockTestCase extends MockObjectTestCase
> > > {
> > >     /**
> > >      * Creates a mock object that mocks the native instance methods for
> the
> > >      * given object.  The mock object is named after the type;  the
> exact
> > >      * name is calculated by { <at> link #defaultNativeMockName}.
> > >      *
> > >      * <at> param mockedInstance The instance to be mocked.
> > >      * <at> return A { <at> link Mock} object that mocks the native methods for
> the
> > >      * given <var>mockedInstance</var>.
> > >      */
> > >     public Mock nativeMock( Object mockedInstance )
> > >     {
> > >         return nativeMock( mockedInstance,
> > >                      defaultNativeMockName(
> mockedInstance ) );
> > >     }
> > >
> > >     /**
> > >      * Creates a mock object that mocks the native instance methods for
> > >      * the given object and is explicitly given a name. The mock object
> > >      * is named after the type;  the exact name is calculated by
> > >      * { <at> link #defaultNativeMockName}.
> > >      *
> > >      * <at> param mockedType The type to be mocked.
> > >      * <at> param roleName The name of the mock object
> > >      * <at> return A { <at> link Mock} object that mocks <var>mockedType</var>.
> > >      */
> > >     public Mock nativeMock( Object mockedInstance, String roleName )
> > >     {
> > >         Mock newMock = new Mock( newNativeCoreMock( mockedInstance,
> roleName
> > > ) );
> > >         registerToVerify(newMock);
> > >         return newMock;
> > >     }
> > >
> > >     protected DynamicMock newNativeCoreMock( Object mockedInstance,
> > >                                              String
> > > roleName )
> > >     {
> > >         return new JniCoreMock( mockedInstance, roleName );
> > >     }
> > >
> > >     public String defaultNativeMockName( Object mockedInstance )
> > >      {
> > >         String className = JniMockUtils.getClass( mockedInstance
> > > ).getName();
> > >
> > >         if( mockedInstance instanceof Class )
> > >         {
> > >             return "jnimock" + className + " <at> static";
> > >         }
> > >         else
> > >         {
> > >             String hash = Integer.toHexString( mockedInstance.hashCode()
> );
> > >
> > >             return "jnimock" + className + " <at> " + hash;
> > >         }
> > >     }
> > > }
> > >
> > >
> > > For my JMock 1 implementation I already have a function that you can
> call to
> > > redirect native calls to an InvocationHandler. You pass an object that
> is
> > > either a class (signifying to
> > >
> > > --
> > > Dale King
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >      http://xircles.codehaus.org/manage_email
> >
> >
>
>
>
> --
> Dale King

---------------------------------------------------------------------
To unsubscribe from this list please visit:

     http://xircles.codehaus.org/manage_email



--
Dale King
Permalink | Reply | 10 comments |
headers
Geoffrey Wiseman | 1 Aug 2007 06:08
Picon
Gravatar

Re: Docs or books on jMock2

On 7/31/07, Anthony Ikeda <anthony.ikeda.cardlink-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

On 7/31/07, Anthony Ikeda < anthony.ikeda.cardlink-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
What is the best documentation for understanding the Expectations syntax (this is introducting a new level of Generics for me that I'm new to)?
The Cookbook for 2.0 seems to be pretty good; what are you having troubles with?
 
Well what I'm having troubles with is the grammer primarily. I've been assuming that the syntax placed betwen the double braces ({{ }}) is processed sequentially. Such that:

Maybe you know this already, or maybe it'll help if I say that this is just Java code.  The new Expectation() { }; sets up an anonymous class, and the inner { } is an instance initializer, a lot like a constructor, but can be used in anonymous classes.

Accordingly, the methods are processed sequentially, yes, when the anonymous class is initialized.

1|{{
2| allow(request).getParameter("j_username");
3| will(returnValue("user"));
4|
5| allow(request).getParameter("j_password");
6| will(returnValue("pass")); 
7|
8| allow(request).getSession();
9| will(returnValue(session));
0|}}
 
Each paired line above is assumed as a kind of workflow. So lines 2 & 3 belong together, as such, as does 5 & 6 and 8 & 9.

That's true; I don't know much about the internals of jMock 2 yet, so I can't tell you how line 3 is associated with line 2, but it is.

Also how do I handle an expectation such as: session.setAttribute("username", name); ?

I'm not sure if I understand the question; you could do:
one(session).setAttribute("username",name);

That assumes that you have a 'name' variable somewhere that the expectation can find, but otherwise it's fine.

Another last point is, what does the double braces signify? This is something new to me as well.

Ah -- well, see above for the explanation.

Here's one example of a writeup of instance initializers, but there are lots out there, just do a Google search:
http://www.developer.com/java/other/article.php/3065621

--
Geoffrey Wiseman
Permalink | Reply | 2 comments |
headers
Nat Pryce | 1 Aug 2007 06:22
Picon

Re: Discussion of opening up Mockery to let it be subclassed

jMock is designed to support a particular style of OO design and
testing.  If you're trying to use it to do something different -- test
static methods, for example -- it will not be a perfect fit.  I'd
rather not keep jMock focused on its core application rather than bend
it too far to support other things.

There doesn't seem to be any reason why an instance with native
methods cannot implement CaptureControl.  Can you not use CGLIB and
Objenesis in the same way as the ClassImposteriser?

--Nat

On 01/08/07, Dale King <dalewking@...> wrote:
> I've gotten my native imposteriser working with JMock2 using the JMock 1
> style expectations.
>
> But it seems to me that it would be possible to refactor the internals of
> JMock to eliminate the thing that keeps you from also using the invocation
> style to specify the expectations for the native methods.
>
> The basic problem is the whole CaptureControl interface assumption that the
> object that the mocked method will be called on (the parameter to the "of"
> method) is an instance of CaptureControl. While that works for the default
> imposertiser it does not work for the native imposteriser. For static native
> methods the parameter is a class and for instance native methods it is just
> an instance, not in any way connected to CaptureControl.
>
> It seems to me that there are ways to eliminate the whole requirement of
> having mock instances implement this CaptureControl interface. You know the
> classes better and how they are isolated from each other, so I'll open the
> question to you to think about while I dig into deciphering the JMock code.
>
>
> On 7/19/07, Nat Pryce <nat.pryce@...> wrote:
> > jMock 2 still has a jmock-1-alike way of specifying expectations
> > without calling methods.  If you use a Matcher (that matches one or
> > more mock objects) instead of directly using a mock object you get
> > given back an interface with chained methods that let you use Matchers
> > to specify the method and arguments.
> >
> > That might work as a plugin-point for what you're trying to achieve.
> >
> > --Nat
> >
> > On 19/07/07, Dale King <dalewking@... > wrote:
> > > After having more time to think about it I realized that Imposterizer is
> > > only the tip of the iceberg. I think that actually isn't a real problem
> as I
> > > can create an imposterizer that says redirect all native method calls
> static
> > > or instance to the given Invokable.
> > >
> > > The whole new way of expressing expectations is not really compatible
> with
> > > native methods.
> > >
> > > First off the assumption that you execute the method you want to mock to
> set
> > > expectations doesn't really work. The static methods are very likely
> private
> > > and it may not be possible/convenient to actually invoke the method for
> > > setting the expectation. This was not a problem with JMock 1 because all
> you
> > > had to do to add expectations was give the name of the method.
> > >
> > > The whole CaptureControl thing and the way expectations are built
> assumes
> > > that you have an instance. That really doesn't work with static methods.
> It
> > > also doesn't work for instance methods as I can't make the instance
> > > implement CaptureControl.
> > >
> > > I want to make it work in the JMock 2 framework, butI think what I will
> have
> > > to create some new classes and cannot rely as heavily on the existing
> stuff.
> > > I will probably have to create a different method for expressing the
> > > expectations that is more JMock 1 like using method names instead of
> relying
> > > on the pattern of invoking the method.
> > >
> > > I've got some more studying and work to do.
> > >
> > >
> > > On 7/19/07, Nat Pryce <nat.pryce@...> wrote:
> > > >
> > > > I don't want to open up the internals of jMock 2.  jMock 1 was *too*
> > > > open and that made it hard to add new features without breaking
> > > > backward compatability, which meant that new features didn't get into
> > > > the library.
> > > >
> > > > jMock 2 has a set of supported extension points defined in terms of
> > > > interfaces and methods that accept those interfaces.
> > > >
> > > > To make jMock2 support your use case we'd need to understand what
> > > > extension points it needs.  What do you need to mock native methods
> > > > beyond what the Imposteriser provides?
> > > >
> > > > --Nat
> > > >
> > > > On 19/07/07, Dale King < dalewking@...> wrote:
> > > > > A while back I developed (but never released) an extension for JMock
> 1
> > > that
> > > > > gave you the ability to extend mocking to native methods. I started
> > > looking
> > > > > at moving it to JMock 2 but it doesn't look like there is any good
> way
> > > to do
> > > > > it because much of the functionality in Mockery is private.
> > > > >
> > > > > Mocking native methods is a bit different from mocking interfaces.
> > > > >
> > > > > First you can mock static native methods in which case you really
> aren't
> > > > > creating an instance you are saying all static native methods for a
> > > given
> > > > > class should be routed to a given InvocationHandler.
> > > > >
> > > > > You can also mock instance native methods. In this case again you
> are
> > > not
> > > > > creating a object instance. Instead you want to pass in an instance
> to
> > > mock
> > > > > the native methods of.
> > > > >
> > > > > The problem is that these don't quite fit into the model of
> Imposterizer
> > > and
> > > > > the mock method of Mockery. You could sort of squeeze mocking of
> static
> > > > > native methods into that mold, but mocking instance native methods
> does
> > > not
> > > > > work due to the need to pass an instance to mock the native methods
> of.
> > > > >
> > > > >  I already have all the working code to handle registering for
> native
> > > method
> > > > > calls to be redirected to a particular InvocationHandler. The hard
> part
> > > is
> > > > > trying to fit this into JMock which is designed under the model of
> > > mocking
> > > > > means creating a new object instance.
> > > > >
> > > > > My first thought was to subclass Mockery to add a new methods
> > > > >
> > > > >    <T> void mockNative( T instanceOrClass );
> > > > >     <T> void mockNative( T instanceOrClass, String name );
> > > > >
> > > > > If you pass a Class object to the method it says to mock the static
> > > native
> > > > > methods. If you pass anything else (other than null) it says to mock
> the
> > > > > instance native methods of that instance.
> > > > >
> > > > > But I find that much of the guts of Mockery was made private which
> > > prevents
> > > > > any useful subclassing. I think that if Mockery.MockObject were
> exposed
> > > that
> > > > > would be enough to allow me to do what I want to do without having
> to
> > > > > duplicate the existing Mockery class.
> > > > >
> > > > > Or perhaps there is another way to better accomplish what I want to
> do.
> > > > >
> > > > > For reference in JMock 1 what I did was create a different CoreMock
> > > class
> > > > > and my own subclass of MockObjectTestCase as follows:
> > > > >
> > > > >  abstract public class JniMockTestCase extends MockObjectTestCase
> > > > > {
> > > > >     /**
> > > > >      * Creates a mock object that mocks the native instance methods
> for
> > > the
> > > > >      * given object.  The mock object is named after the type;  the
> > > exact
> > > > >      * name is calculated by { <at> link #defaultNativeMockName}.
> > > > >      *
> > > > >      *  <at> param mockedInstance The instance to be mocked.
> > > > >      *  <at> return A { <at> link Mock} object that mocks the native methods
> for
> > > the
> > > > >      * given <var>mockedInstance</var>.
> > > > >      */
> > > > >     public Mock nativeMock( Object mockedInstance )
> > > > >     {
> > > > >         return nativeMock( mockedInstance,
> > > > >                      defaultNativeMockName(
> > > mockedInstance ) );
> > > > >     }
> > > > >
> > > > >     /**
> > > > >      * Creates a mock object that mocks the native instance methods
> for
> > > > >      * the given object and is explicitly given a name. The mock
> object
> > > > >      * is named after the type;  the exact name is calculated by
> > > > >      * { <at> link #defaultNativeMockName}.
> > > > >      *
> > > > >      *  <at> param mockedType The type to be mocked.
> > > > >      *  <at> param roleName The name of the mock object
> > > > >      *  <at> return A { <at> link Mock} object that mocks
> <var>mockedType</var>.
> > > > >      */
> > > > >     public Mock nativeMock( Object mockedInstance, String roleName )
> > > > >     {
> > > > >         Mock newMock = new Mock( newNativeCoreMock( mockedInstance,
> > > roleName
> > > > > ) );
> > > > >         registerToVerify(newMock);
> > > > >         return newMock;
> > > > >     }
> > > > >
> > > > >     protected DynamicMock newNativeCoreMock( Object mockedInstance,
> > > > >                                              String
> > > > > roleName )
> > > > >     {
> > > > >         return new JniCoreMock( mockedInstance, roleName );
> > > > >     }
> > > > >
> > > > >     public String defaultNativeMockName( Object mockedInstance )
> > > > >      {
> > > > >         String className = JniMockUtils.getClass( mockedInstance
> > > > > ).getName();
> > > > >
> > > > >         if( mockedInstance instanceof Class )
> > > > >         {
> > > > >             return "jnimock" + className + " <at> static";
> > > > >         }
> > > > >         else
> > > > >         {
> > > > >             String hash = Integer.toHexString(
> mockedInstance.hashCode()
> > > );
> > > > >
> > > > >             return "jnimock" + className + " <at> " + hash;
> > > > >         }
> > > > >     }
> > > > > }
> > > > >
> > > > >
> > > > > For my JMock 1 implementation I already have a function that you can
> > > call to
> > > > > redirect native calls to an InvocationHandler. You pass an object
> that
> > > is
> > > > > either a class (signifying to
> > > > >
> > > > > --
> > > > > Dale King
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >      http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dale King
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >      http://xircles.codehaus.org/manage_email
> >
>
>
>
> --
> Dale King

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 9 comments |
headers
Nat Pryce | 1 Aug 2007 06:26
Picon

Re: Docs or books on jMock2

On 01/08/07, Anthony Ikeda <anthony.ikeda.cardlink@...> wrote:
> How do I mock outputstreams so I can read output from classes such as a
> servlet or JSP?

For this I think you'd be better off running the servlet or JSP in the
servlet container and testing the result of HTTP gets and posts.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |
headers
Anthony Ikeda | 1 Aug 2007 06:36
Picon

Re: Docs or books on jMock2

Thanks for your help Geoff, it certainly clarifies alot of assumptions made so far. As for the below:
 

 
Also how do I handle an expectation such as: session.setAttribute("username", name); ?

I'm not sure if I understand the question; you could do:
one(session).setAttribute("username",name);

That assumes that you have a 'name' variable somewhere that the expectation can find, but otherwise it's fine.
 
 
I have the following lines of code in my servlet:
 
String name = request.getParameter("j_username");
HttpSession session = request.getSession();
session.setAttribute("name", name");
 
If I mock the objects as follows:
 
HttpSession session = mockery.mock(HttpSession.class);
HttpServletRequest request = mockery.mock(HttpServletRequest.class);
 
String name = "anthony";
 
mockery.checking(new Expectations() {{
 
allow(request).getSession();
will(returnValue(session));
 
allow(request).getParameter("j_username");
will(returnValue(name));
 
}});
 
Ergo, the code should use the "mocked" value for name as "anthony" for
 
String name = request.getParameter("j_username")
 
However running the code reveals an Expectation not being set for
 
session.setAttribute("name", name);
 
To set an expectation for the session.setAttribute:
 
String name = "anthony";
 
mockery.checking(new Expectations() {{
one(session).setAttribute("username",name);
}});
 
Doesn't really make sense as I would be somehow introducing a process that is not quite consistent, the value for "name" should be the one that is encapsulated inside the application login not "injected" as such.
 
In my test I would like to able to see: assertNotNull(session.getAttribute("name")); return a true value based on the value from the request, not the expectation. Confusing I know cause they are supposed to be the same value but the value is not part of the flow so to speak if I "Expect" it for the session.setAttribute() method. Make sense?
 
Anthony
 
Permalink | Reply | 1 comment |
headers
Anthony Ikeda | 1 Aug 2007 06:44
Picon

Re: Docs or books on jMock2

Okay, seems I'm taking this to an extreme that doesn't need to be - I'm not aupposed to be testing the the session logic am I?!
 
So it makes sense to omit an:
 
assertNotNull(session.getAttribute("name"));
 
becuase it is a mocked object ergo nothing would be returned.
 
Sorry major headspin over this.
 
Anthony

 
On 8/1/07, Nat Pryce <nat.pryce-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On 01/08/07, Anthony Ikeda <anthony.ikeda.cardlink-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
> How do I mock outputstreams so I can read output from classes such as a
> servlet or JSP?

For this I think you'd be better off running the servlet or JSP in the
servlet container and testing the result of HTTP gets and posts.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list please visit:

   http://xircles.codehaus.org/manage_email


Permalink | Reply | 0 comments |

Gmane