headers
DispatchMediaGroup | 15 Nov 21:08
Favicon

How to Spy a Method


Hey all, need a little help here.

I've been writing unit tests now for about a month or so, retroactively. 
That is, we are trying to get to a test-driven development paradigm, but for
now, we need to cover our existing code base.  We are using JUnit 3 and
JMock 2.5.1.

The issue is as such:

I have a method of a class that I wish to test.  It does certain things
depending on parameter state, like any good ole method.  However, at the end
of this method's execution, it daisy-chains to another method.  This second
method is not one that we wish to test, especially as its code just creates
an HTTP connection to a URL and posts a message there.  I want to write my
tests and expectations in such a way that I can expect the method
invocation, but not actually execute the code in that method.

Now, having done quite a bit of reading and Googling about this, I have not
been able to find the answer I need, but what I want to do is apparently
called 'method spying'.  Any idea how to do this?  This is a scenario where
I must stay within the constraints of the existing environment (no new jars,
no new frameworks - just JUnit and JMock).

Example:

public class SomeClass
{
     private static final SomeClass INSTANCE = new SomeClass();
(Continue reading)

Permalink | Reply | 8 comments |
headers
Richard Rothwell | 16 Nov 01:56
Picon
Favicon

Re: How to Spy a Method

This scenario happens a lot.

I have heard mention of an extension to do this but don't know how to track
it down.

My own solution is to ensure such methods are protected/public and to test
not the actual class, but a subclass in which the method to be
neutralised/(stubbed out) aka method2 is overridden and reimplemented with
no internal behavior.

The parameters expected to be passed in to the stubbed out method can be
asserted as an additional frill.

Regards from Richard Rothwell

On 16/11/11 7:08 AM, "DispatchMediaGroup" <digitalit@...> wrote:

> 
> Hey all, need a little help here.
> 
> I've been writing unit tests now for about a month or so, retroactively.
> That is, we are trying to get to a test-driven development paradigm, but for
> now, we need to cover our existing code base.  We are using JUnit 3 and
> JMock 2.5.1.
> 
> The issue is as such:
> 
> I have a method of a class that I wish to test.  It does certain things
> depending on parameter state, like any good ole method.  However, at the end
> of this method's execution, it daisy-chains to another method.  This second
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Macgilvery | 16 Nov 10:30
Picon
Favicon

RE: How to Spy a Method

Hi,
        How much control do you have over the refactoring of SomeClass?
Does it have to be a static Singleton, or are you able to change SomeClasses invocation in your project?
Avoiding static Singleton makes your code easier to test, but if not then using a SomeClassFactory may help.

If you can break out the message sending part of the code into a separate interface, it will be much easier to test.

Regards,

        Andy

________________________________

This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Andrew Macgilvery | 16 Nov 11:49
Picon
Favicon

RE: How to Spy a Method

If you are able to modify the code, here's is a zip of example classes and tests that will let you test your
logic without executing the HTTP section of your code, but will send http messages at runtime (if you use
the 'factory').

As you're striving to get an existing codebase under test I highly recommend the book "Working Effectively
with Legacy Code" by Michael Feathers, a real revelation on how to get your code under test!

Regards,

        Andy

http://dl.dropbox.com/u/3057644/SomeClassJMock.zip

-----Original Message-----
From: DispatchMediaGroup [mailto:digitalit@...]
Sent: 15 November 2011 20:09
To: user@...
Subject: [jmock-user] How to Spy a Method

Hey all, need a little help here.

I've been writing unit tests now for about a month or so, retroactively.
That is, we are trying to get to a test-driven development paradigm, but for
now, we need to cover our existing code base.  We are using JUnit 3 and
JMock 2.5.1.

The issue is as such:

I have a method of a class that I wish to test.  It does certain things
depending on parameter state, like any good ole method.  However, at the end
(Continue reading)

Permalink | Reply | 0 comments |
headers
DispatchMediaGroup | 16 Nov 16:56
Favicon

Re: How to Spy a Method


DispatchMediaGroup wrote:
> 
> Hey all, need a little help here.
> 
> I've been writing unit tests now for about a month or so, retroactively. 
> That is, we are trying to get to a test-driven development paradigm, but
> for now, we need to cover our existing code base.  We are using JUnit 3
> and JMock 2.5.1.
> 
> The issue is as such:
> 
> I have a method of a class that I wish to test.  It does certain things
> depending on parameter state, like any good ole method.  However, at the
> end of this method's execution, it daisy-chains to another method.  This
> second method is not one that we wish to test, especially as its code just
> creates an HTTP connection to a URL and posts a message there.  I want to
> write my tests and expectations in such a way that I can expect the method
> invocation, but not actually execute the code in that method.
> 
> Now, having done quite a bit of reading and Googling about this, I have
> not been able to find the answer I need, but what I want to do is
> apparently called 'method spying'.  Any idea how to do this?  This is a
> scenario where I must stay within the constraints of the existing
> environment (no new jars, no new frameworks - just JUnit and JMock).
> 

Saw a couple of replies this morning - thank you!

That said, here's what I've been able to do for now: I did break out the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Macgilvery | 16 Nov 17:21
Picon
Favicon

RE: How to Spy a Method

Hi DMG,

        I advised against static singletons because they are difficult to test, and difficult to sub-class.
Did you manager to see the code in the zip I posted?
If you pass the dependencies that a class requires into the class at creation time (via the constructor),
you can be sure that the class has everything it needs to do its job, and you can modify the behaviour of the
class at class creation time (as with the Mock in the test for SomeClass in the zip file I posted).

I prefer to pass dependencies into a constructor rather than into setter methods, because you (or someone
else using your code after you have moved onto another project or employer) may forget to call a setter and
cause errors to occur.

Instances of classes can be written so that a methods executed on the class are independent of state, if that
is a requirement for your project.

Injecting dependencies into a class via constructor is also covered now by Spring and other dependency
injection frameworks, which will help in migrating to them when (or if :-) ) you're ever allowed to
introduce new jars into your project.

Regards,

        Andy

-----Original Message-----
From: DispatchMediaGroup [mailto:digitalit@...]
Sent: 16 November 2011 15:57
To: user@...
Subject: Re: [jmock-user] How to Spy a Method

DispatchMediaGroup wrote:
(Continue reading)

Permalink | Reply | 3 comments |
headers
DispatchMediaGroup | 16 Nov 20:45
Favicon

RE: How to Spy a Method


I did look at your example, thank you.  

The approach I've ended up taking is very close to what you suggest.  I did
not use a factory, and instead continued with my singleton approach, but I
do use the dependency injection.  Now, instead of requiring an instantiation
of a class to take the in the required dependencies, I inject them in the
private constructor at class creation, ensuring that the class has what it
needs in order to function; an implementing class could alter those
dependencies using the associated setter.  I have an inkling that your
methodology is probably more correct than mine, though...  

And a newbie question now: how is your factory really any different than my
singleton class?

Andrew Macgilvery wrote:
> 
> Hi DMG,
> 
>         I advised against static singletons because they are difficult to
> test, and difficult to sub-class.
> Did you manager to see the code in the zip I posted?
> If you pass the dependencies that a class requires into the class at
> creation time (via the constructor), you can be sure that the class has
> everything it needs to do its job, and you can modify the behaviour of the
> class at class creation time (as with the Mock in the test for SomeClass
> in the zip file I posted).
> 
> I prefer to pass dependencies into a constructor rather than into setter
> methods, because you (or someone else using your code after you have moved
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Rothwell | 17 Nov 01:00
Picon
Favicon

Re: How to Spy a Method

As an example of my method stubbing approach, obviously it does not used
mocks, is as follows:

You will notice that the only potential modification to class under test
is that the method call you want to disable cannot be private.
There are even work arounds for that via reflection.

Regards from Richard Rothwell

//-------------------------------------------------------------
CLASS UNDER TEST
//-------------------------------------------------------------
package au.com.ace;

public class ExploreTheWeb
{
    public void runAroundMadly()
    {
        pokeThatSite();
    }

    protected void pokeThatSite()
    {
        System.out.println("Sending HTTP request to get page");
    }
}
//-------------------------------------------------------------
TESTER
//-------------------------------------------------------------
package au.com.ace;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Macgilvery | 17 Nov 11:27
Picon
Favicon

RE: How to Spy a Method

Hi DMG,
        It's not really different, so it's not a good example :-(.
There are some benefits to that structure.
The factory is a static singleton, but by having a class that is only concerned with the creation of an
object, you are aligning your code with the Single Responsibility Principle.
The SomeClass object is now testable and can be created by an IOC container if you get a chance to move at a
later date.
By extracting the HTTP messaging call into another class, you have also removed the messaging code from
"SomeClass", creating a better separation of concerns.
This allows you to reuse your http code elsewhere, and easily replace it if you change your messaging medium.
It doesn't rely on exposing internal methods for testing purposes.

What kind of an app are you refactoring? A Web-app, library, thick client, command line etc?

Kind Regards,
    Andy

-----Original Message-----
From: DispatchMediaGroup [mailto:digitalit@...]
Sent: 16 November 2011 19:46
To: user@...
Subject: RE: [jmock-user] How to Spy a Method

I did look at your example, thank you.

The approach I've ended up taking is very close to what you suggest.  I did
not use a factory, and instead continued with my singleton approach, but I
do use the dependency injection.  Now, instead of requiring an instantiation
of a class to take the in the required dependencies, I inject them in the
private constructor at class creation, ensuring that the class has what it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aram | 30 Nov 00:21
Picon

using DeterministicScheduler as an ExecutorService

I would like a suggestion/feedback for getting around the issue of getting an 
UnsupportedSynchronousOperationException when using DeterministicScheduler.  

Is there a workaround?  Or a suggestion of how I can proceed?

Also, I am kind of confused about what the following means: "The scheduler does 
not implement the synchronous methods of the SchedulerExecutorService interface. 
If a test attempts to do a blocking wait for a scheduled task to complete".  Can 
someone help me understand this.

I am trying to do some T-D-D using JMock in creating tests/class that support 
asynchronous code.  My design uses the Producer-Consumer pattern and my story 
requirements are that my processes in my consumer class run on their own 
"worker" thread.  

What I am really trying to do is use DeterministicScheduler, simply for it's 
implementation of ExecutorService, which will can return to me a Future<T> that 
my class can process and can do something with upon a 
DeterministicScheduler.submit(Callable<T>).

I have been relying heavily on the CookBook pages 
(http://www.jmock.org/threading-scheduler.html, 
http://www.jmock.org/threads.html). 

So, I have been using DeterministicScheduler as an ExecutorService in my test 
class:

public someTestClass {
  private DeterministicScheduler _executorService = new 
DeterministicScheduler();
(Continue reading)

Permalink | Reply | 0 comments |

Gmane