gmane.comp.java.jmock.user

Re: Ignoring calls to static methods

Steve Freeman — 2010-02-09T22:21:36

There are other frameworks that do that sort of thing. I tend to think it's a bad idea. The relevant point here is that the B singleton is a dependency. You can either hide it in A or make it explicit and pass it in, perhaps when A is constructed. Whether you need to wrap B depends on what it is and what you do with it.

S

On 9 Feb 2010, at 14:04, Panos Konstantinidis wrote:

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited.  http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ. 
Company registered in England & Wales. Number 03689627




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

    http://xircles.codehaus.org/manage_email

Re: Ignoring calls to static methods

Panos Konstantinidis — 2010-02-09T14:04:56

Hello Steve, 

yes I do have access to class A, this is the class I wrote. And you are right, I could introduce an object C, that wraps access to class B. But again there are two concerns here: 

a) I introduce a third object just to test my first object, and
b) I need to change the source code of class A, because I need a way to pass this wrapper object to the mockery context, otherwise I couldn't be able to set expectations on it and mock the functionality. So, as you say I will need to test it in an integration test, which is already being done for the current class B.

I was wondering if there is a simple way, something like (if "context" is of type Mockery)

mockery.ignoreClass(B.class);

I know that JMock uses reflection to mock interfaces JMock works, but I guess, since it's using cglib, it has some interaction at byte code level. My original thought was that maybe someone knows how to bypass byte code calls through JMock.

Regards

Panos

--- On Tue, 2/9/10, steve-/6t1Ty3A97Vaa/9Udqfwiw< at >public.gmane.

Re: Ignoring calls to static methods

2010-02-09T13:36:47

If you have access to class A, you could consider wrapping the access 
to class B in an object (c) that will return the instance. That breaks 
the static dependency and makes the code testable. You can then test 
the implementation of (c) in an integration test, if it's at all 
complicated, or just let the acceptance tests exercise it.

Another option to consider is whether you could pass an instance of B 
into A, perhaps on construction. Again, this doesn't make the probably 
totally disappear, but makes A's dependencies clearer and easier to 
work with.

S.

On 9 February, 2010, Panos Konstantinidis <girionis-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> wrote:


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

    http://xircles.codehaus.org/manage_email

Re: Ignoring calls to static methods

Panos Konstantinidis — 2010-02-09T12:04:12

Hello Julian, thank you for your prompt reply

allowing you to override the 
your test setups to inject a mock.

Unfortunatelly I cannot modify the code (I am not even sure if they have the code anymore), I can only call the static methods on the class. And unfortunatelly I cannot set expectations on the class with the static methods, since it's not in the mock's context. I am stumped right now and I am thinking of just abandoning this specific unit test, and let the functional testing catch any (possible) errors. But I am pretty sure that I will encounter this situation again, and I was thinking if there is an easy solution to this.

Regards

Panos

Re: Ignoring calls to static methods

Julian Hall — 2010-02-09T10:49:26

Are you free to modify B?  If so, I'd add a method setInstance, allowing 
you to override the default value returned, and call it from your test 
setups to inject a mock.

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

    http://xircles.codehaus.org/manage_email

Ignoring calls to static methods

Panos Konstantinidis — 2010-02-09T09:52:03

Hello my name is Panos, I am new to the list (although not to jmock since I've been using it for the last coupel of years).

I came across a situation that I need to re-use some legacy code that has loads of calls to static methods. For example consider the following example

class A
{
   B.instance().sayHello();
}

class B
{
   public static instance()
   {
      ...
      return B;
   }

   public String sayHello()
   {
      return "hello";
   }
}

I am testing class A with jMock. Is there a way to instruct jMock to completely ignore the call to B.instance().sayHello();? Normally this wouldn't be a problem but the call to instance() returns null sometimes and subsequently throws a npe.

I know that I could refactor the code and use the Strategy pattern but refactoring it is out of the question, I cannot touch the legacy code.

The other thing I can think of is to catch the npe and continue normally but this is not a good programming practice. So I am looking for a way (if ther

AW: Testing method which is accepting String... as parameter

Günther, Rene - Innflow AG — 2010-01-19T14:16:25

Looks like we got it working now with with(equal(new
String[]{Constants.ADMIN}))

 

Cheers

Rene

 

Von: "Günther, Rene - Innflow AG" [mailto:rene.guenther-WbT5Zv7j22JBDgjK7y7TUQ< at >public.gmane.org] 
Gesendet: Dienstag, 19. Januar 2010 15:01
An: user-sXN/XchZ9OexIXFVlbCvtR2eb7JE58TQ< at >public.gmane.org
Betreff: [jmock-user] Testing method which is accepting String... as
parameter

 

Hi,

 

we are having the following method on our interface: findByRoles(String
roles)

 

We are calling it like that: findByRole(admin);

 

We tried to set the expectation
one().findByRoles(with(equal(Constants.ADMIN));

 

Which caused unexpectedInvocationException.

Is there a special handling for that kind of parameters (variable length
arguments)?

 

Thanks

Rene

Testing method which is accepting String... as parameter

Günther, Rene - Innflow AG — 2010-01-19T14:00:37

Hi,

 

we are having the following method on our interface: findByRoles(String
roles)

 

We are calling it like that: findByRole(admin);

 

We tried to set the expectation
one().findByRoles(with(equal(Constants.ADMIN));

 

Which caused unexpectedInvocationException.

Is there a special handling for that kind of parameters (variable length
arguments)?

 

Thanks

Rene

Re: strange jmock behaviour in case of different results expected for same function for different parameters

James Abley — 2010-01-05T19:59:38

2010/1/5 Ralph Urban <rurban-Hst+yzLCD1M< at >public.gmane.org>

Can you send a more complete example? I can't see where the
propertyStorageLocal or propertyStorageLocalHome mocks are defined, or the
create() method is called.

Cheers,

James

strange jmock behaviour in case of different results expected for same function for different parameters

Ralph Urban — 2010-01-05T11:30:36

Hi,

I am mocking a bean. Its function getPackages is called twice, both calls with
diferent parameters. The function should return diffent lists. Somehow JMock
merges these lists. Did I specifiy wrongly?

Test1:
    < at >Test
    public void testStrangeMock() {
        final List<String> packages2 = new ArrayList<String>();
        packages2.add("de.psi.telco.mccm");
        final List<String> packages = new ArrayList<String>();
        packages.add("de.psi.telco.mccm.test1");
        packages.add("de.psi.telco.mccm.test2");
        mMockery.checking(new Expectations() {{
            allowing (mPropS).getPackages(with(equal("de.psi.telco.mccm")), 
                    with(equal(true)));
                will(returnValue(packages));
                allowing (mPropS).getPackages(with(equal("de.psi.telco")), 
                with(equal(false)));
                will(returnValue(packages2));
        }});
        
        Map<String,AbstractMCCMProperty> results = mLdap.getPropertiesMap(
                "dc=mccm,dc

Re: Failing a test in a separate thread

Toby — 2009-12-23T16:47:01

Thanks for that, I took a look and the Synchroniser and came up with
something similar as a JUnit Statement.

http://code.google.com/p/tempus-fugit/source/browse/trunk/tempus-fugit/src/main/java/com/google/code/tempusfugit/concurrency/RunConcurrently.java

I couldn't quite see how the Synchroniser fits together fully with the rest
of the framework but it inspired me into thinking about an object which
stashes the Exception to be queried later. If you got a chance, any feedback
on the above would be appreciated (please be kind!), its more of a spike
than anything and I'm not even sure its of any real use but it does
something similar to
http://blog.mycila.com/2009/11/writing-your-own-junit-extensions-using.html.

My associated test is

http://code.google.com/p/tempus-fugit/source/browse/trunk/tempus-fugit/src/test/java/com/google/code/tempusfugit/concurrency/RunConcurrentlyTest.java

ps, hope this isn't too off topic :D

Cheers
Toby

2009/12/21 Nat Pryce <nat.pryce-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: Failing a test in a separate thread

Toby — 2009-12-21T18:38:22

A ha! Cheers I'll take a look...

Toby


On 21 Dec 2009, at 16:34, Nat Pryce <nat.pryce-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


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

    http://xircles.codehaus.org/manage_email

Re: Failing a test in a separate thread

Nat Pryce — 2009-12-21T16:34:53

Yes.  Have a look at the Synchroniser class in subversion head.  It
catches an exception thrown by any mock object on any thread and
ensures that the first exception is rethrown when the test calls
assertIsSatisfied on the test-runner's thread.

You could probably do something similar using a JUnit rule, as long as
the rule object started all the threads used by your tests.

--Nat

2009/12/20 Toby <toby.weston-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:

Failing a test in a separate thread

Toby — 2009-12-20T12:55:53

Bit of an odd question, but bear with me...

I'm playing with running test methods from JUnit in their own thread (just
for fun) but of course, any Assert.fail will not make its way back to the
main JUnit thread and so not fail the test. I was wondering if JMock has
come across the same issue, any suggestions on an approach?

The closest I've got to so far is using the very naughty
Thread.stop(Throwable), something like this (although I know I can't really
use this, it does illustrate the kind of thing I want);

   < at >Test
    public void failureInAnotherThread() throws InterruptedException {
        final Thread main = Thread.currentThread();
        Thread thread = new Thread(new Runnable() {
            public void run() {
                fail("grrr!");
            }
        });
        thread.setUncaughtExceptionHandler(new
Thread.UncaughtExceptionHandler() {
            public void uncaughtException(Thread t, Throwable e) {
                main.stop(e);
            }
        });
        thread.start();

Re: Checkstyle check for < at >RunWith(JMock)

Nat Pryce — 2009-12-03T21:38:41

2009/11/23 Stephen Smith <steve-cOXOJo/IntmS2QFrQHbrDfXRex20P6io< at >public.gmane.org>:

If you want to use a different test runner (e.g. parameterised test
runner) you have to call context.assertIsSatisfied() explicitly.

The new Rules mechanism in JUnit avoids this limitation.

--Nat

Re: Re: Peculiar expectation error

Nat Pryce — 2009-12-03T20:07:25

2009/11/30 Sam <mail-zhSKZATnOKPOK8mupsKPhw< at >public.gmane.org>:

Not in TestNG.  In TestNG, all tests of the same class run in the same
instance of that class and the onus is on you to make sure the tests
don't interfere with one another.

--Nat

Re: Mocking Static Methods using JMock

Nat Pryce — 2009-12-03T20:04:56

Does the static method have side effects (e.g. change mutable static
state)?  If so, it's probably best to turn that into an object and
give it an interface.  You can then mock the interface.

If it's a pure function with no side effects, then there's no problem
with giving the object under test known inputs and testing how it uses
the known outputs from the pure function.

If you want to ignore the complexity of the function when testing,
then I think you should apply the Strategy pattern.  Introduce an
interface between the object under test and the strategy, use a
strategy implementation that calls (or replaces) the static function
in production code, and use stub implementation in tests.

--Nat

2009/12/1 Siddhi B <borkar.siddhi-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:

Re: Mocking Static Methods using JMock

Siddhi B — 2009-12-01T09:50:30

Thanks for your quick reply Steve.
The above code snippet was just a simple example. The code that I am working
on contains complex logic in the static function.



Steve Freeman-2 wrote:

Re: Mocking Static Methods using JMock

Steve Freeman — 2009-12-01T07:51:52

We don't support mocking of static methods since there is almost  
always a better way. That might mean testing it directly in an  
integration test or writing a thin layer above the static method and  
testing against /that/.

If your method is as simple as getName() it might be better to just  
call the method.
S.

On 1 Dec 2009, at 03:37, Siddhi B <borkar.siddhi-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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

    http://xircles.codehaus.org/manage_email

Mocking Static Methods using JMock

Siddhi B — 2009-12-01T03:37:33

Hi,

I need a way of mocking a static class using JMock. Consider the following
code snippet.

public class A {
   void functionX() {
       String name =  ClassB.getName(); // Static function
   }
}

public class ClassB {
    static String getName() {
        return 'ABC'
    }
}

I need a way of mocking the static function 'getName'.Please note that I do
not have rights to modify the legacy code.

Any help would be highly appreciated.

Thanks,
Siddhi

Re: Peculiar expectation error

Sam — 2009-12-01T00:28:11

Problem solved. Moved test fixture to < at >BeforeMethod annotated method and create
new Mockery object before any fixture code executed.

Cheers,
Sam 




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

    http://xircles.codehaus.org/manage_email