Block support? about ocmockito HOT 21 CLOSED

vote+1

from ocmockito.

+1 from me as well.

from ocmockito.

Noted, and keeping this issue open.

from ocmockito.

+1 for me too

from ocmockito.

+1 for me too

from ocmockito.

+1

from ocmockito.

+2! (I'm pairing - they agree ;) )

from ocmockito.

+3 since we have 3 ppl using them

from ocmockito.

OK, lots of interest in this! I assume the main need is the ability to mock a method that takes block arguments. So here's my question: What would you verify against a given block argument? Or would you want OCMockito to silently ignore it, checking the other arguments?

from ocmockito.

I'd say accepting not nil, not null matchers and ignoring it on verify otherwise

from ocmockito.

At the time I added my vote, I was trying to test a network sync class which in turn uses a REST client class (subclass of AFHTTPClient). I wanted to mock the REST client class so that I could simulate various network responses, both failures and successful results. The REST client consists mainly of async networking API methods that use a success block to callback with results and a failure callback with HTTP error codes, etc

I was trying to use OCMockito to mock the REST client and set it up to respond with specific success results or failure codes to ensure correct functionality of the sync class. Ultimately I ended up mocking the client by subclassing and overriding the various async methods. The tests would give the mock client a mock response object and the overridden methods would immediately (synchronously) call one of the two blocks with the prescribed response values.

This actually worked really well and was quite minimal in terms of code, but maybe there is a more elegant way to do this more generally if OCMockito were extended in some way.

from ocmockito.

@metatation, that's a great example of when not to use a mocking framework like OCMockito. Subclass and Override Method is a powerful tool — don't let the existence of mocking frameworks fool you into thinking they can do better than you!

from ocmockito.

Thanks for that last answer @jonreid, I've been using mocks primarily for that use case, not seeing the easily implemented solution right in front of my face. Thanks!

from ocmockito.

Personally I'd like to capture the block arguments so that I can call them and verify they work as expected based on the parameters given. :)

from ocmockito.

+1

from ocmockito.

@codyaray: that's exactly what I need too. I find myself having to hand-roll quite a few mocks to capture block arguments.

from ocmockito.

I like the idea of being able to capture block based arguments. Most APIs are heading this way now and the easier it is to mock / stub these, the more likely they'll be tested. As @metatation mentioned, this is quite popular in network calls. Capturing blocks also allows you to do synchronous testing.

While you can subclass and override, this is such a common occurrence that you'd end up subclassing most of the classes in your project.

My two cents. I've also included an example from Kiwi below.

Kiwi has an option for stub:withBlock: which allows you to capture blocks passed to a method and then you can call them directly with whatever params you want in your test. This creates a really easy way to stub block based apis.

For example, if you have an object with a method refresh

- (void)refresh
{
  [self.fetcher fetchAllWithCompletion:^(NSError* error){
     // do stuff
  }];
}

The goal being that in your test case you can essentially do the following:

- (void)testRefreshShowsAnAlertWhenErrorOccurs
{

   // set up other stuff
....

// stub the block api and call the block synchronously
     [fetcherMock stub:@selector(fetchAllWithCompletion:) withBlock:^ id (NSArray *params) {
                __block void(^block)(NSError *) = params[0];
                block([NSError nullMock]);
                return nil;
            }];


// call the method under test
    [object refresh];

// verify behaviour
    [verfiy(alertMock) show];
}

I haven't used OCMock before, but I assume [[mock stub] andDo:theBlock] offers similar functionality.

from ocmockito.

I also would really welcome any implementation of this behavior. Is there anything coming up?

from ocmockito.

I've started work on a way to capture arguments. Then you can get your blocks back and invoke them as you like.

from ocmockito.

Give it a try! See ArgumentCaptorTest.m for examples.

from ocmockito.

Thanks a lot on adding this! Is the pod spec for this project going to update? Which version of the library had this support?

from ocmockito.