How to mock location service using KIF-framework

Question

I use KIF framework (http://github.com/kif-framework/KIF) for UI Tests and I need to mock location service.

The problem is location service starts BEFORE KIF method -beforeAll invoked. So it's too late to mock.

Any suggestions would be appreciated.

Answer 1

In my KIF target I have a BaseKIFSearchTestCase : KIFTestCase, where I overwrite CLLocationManager`s startUpdatingLocation in a category.

Note that this is the only category overwrite I ever made as this is really not a good idea in general. but in a test target I can accept it.

#import <CoreLocation/CoreLocation.h>

#ifdef TARGET_IPHONE_SIMULATOR


@interface CLLocationManager (Simulator)
@end

@implementation CLLocationManager (Simulator)
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation"

-(void)startUpdatingLocation 
{
    CLLocation *fakeLocation = [[CLLocation alloc] initWithLatitude:41.0096334 longitude:28.9651646];
    [self.delegate locationManager:self didUpdateLocations:@[fakeLocation]];
}
#pragma clang diagnostic pop

@end
#endif // TARGET_IPHONE_SIMULATOR



#import "BaseKIFSearchTestCase.h"

@interface BaseKIFSearchTestCase ()

@end

@implementation BaseKIFSearchTestCase
 //...

@end

---

Cleaner would be to have a subclass of CLLocationManager in your application target and another subclass with the same name in your test target that send fake location like shown above. But if this is possible depends on how your test target is set up, as it actually need to be an application target as Calabash uses it.

---

Yet another way:

• in your project create another configuration "Testing", cloning "Debug"

• add the Preprocessor Macro TESTING=1 to that configuration.

• Subclass CLLocationManager

• use that subclass where you would use CLLocaltionManger

• conditionally compile that class

  #import "GELocationManager.h"
  
  @implementation GELocationManager
  -(void)startUpdatingLocation
  {
  
  #if TESTING==1
  #warning Testmode
  
  dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
          CLLocation *fakeLocation = [[CLLocation alloc] initWithLatitude:41.0096334 longitude:28.9651646];
          [self.delegate locationManager:self didUpdateLocations:@[fakeLocation]];
      });
  
  #else
      [super startUpdatingLocation];
  #endif
  
  }
  @end
  

• in your test targets scheme choose the new configuration

---

And yet another option:

Probably the best: no code needs to be changed.

Answer 2

As usual, a couple of ways to do this. The key is not to try to mock out the existing location service but to have a completely different mock you can get access to at run time. The first method I'm going to describe is basically building your own tiny DI container. The second method is for getting at singletons you don't normally have access to.

1) Refactor your code so that it doesn't use LocationService directly. Instead, encapsulate it in a holder (could be a simple singleton class). Then, make your holder test-aware. The way this is works is you have something like a LocationServiceHolder that has:

// Do some init for your self.realService and make this holder
// a real singleton.

+ (LocationService*) locationService {
  return useMock ? self.mockService : self.realService;
}

- (void)useMock:(BOOL)useMock {
  self.useMock = useMock;
}

- (void)setMock:(LocationService*)mockService {
  self.mockService = mockService;
}

Then whenever you need your locationService you call

[[LocationServiceHolder sharedService] locationService];  

So that when you're testing, you can do something like:

- (void)beforeAll {
  id mock = OCClassMock([LocationService class]);
  [[LocationServiceHolder sharedService] useMock:YES]];
  [[LocationServiceHolder sharedService] setMock:mock]];
}

- (void)afterAll {
  [[LocationServiceHolder sharedService] useMock:NO]];
  [[LocationServiceHolder sharedService] setMock:nil]];      
}

You can of course do this in beforeEach and rewrite the semantics to be a bit better than the base version I'm showing here.

2) If you are using a third party LocationService that's a singleton that you can't modify, it's slightly more tricky but still doable. The trick here is to use a category to override the existing singleton methods and expose the mock rather than the normal singleton. The trick within a trick is to be able to send the message back on to the original singleton if the mock doesn't exist.

So let's say you have a singleton called ThirdPartyService. Here's MockThirdPartyService.h:

static ThirdPartyService *mockThirdPartyService;

@interface ThirdPartyService (Testing)

+ (id)sharedInstance;
+ (void)setSharedInstance:(ThirdPartyService*)instance;
+ (id)mockInstance;

@end

And here is MockThirdPartyService.m:

#import "MockThirdPartyService.h"
#import "NSObject+SupersequentImplementation.h"

// Stubbing out ThirdPartyService singleton
@implementation ThirdPartyService (Testing)

+(id)sharedInstance {
    if ([self mockInstance] != nil) {
        return [self mockInstance];
    }
    // What the hell is going on here? See http://www.cocoawithlove.com/2008/03/supersequent-implementation.html
    IMP superSequentImp = [self getImplementationOf:_cmd after:impOfCallingMethod(self, _cmd)];
    id result = ((id(*)(id, SEL))superSequentImp)(self, _cmd);
    return result;
}

+ (void)setSharedInstance:(ThirdPartyService *)instance {
    mockThirdPartyService = instance;
}

+ (id)mockInstance {
    return mockThirdPartyService;
}

@end

To use, you would do something like:

#include "MockThirdPartyService.h"

...

id mock = OCClassMock([ThirdPartyService class]);
[ThirdPartyService setSharedInstance:mock];

// set up your mock and do your testing here

// Once you're done, clean up.
[ThirdPartyService setSharedInstance:nil];
// Now your singleton is no longer mocked and additional tests that
// don't depend on mock behavior can continue running.

See link for supersequent implementation details. Mad props to Matt Gallagher for the original idea. I can also send you the files if you need.

Conclusion: DI is a good thing. People complain about having to refactor and having to change your code just to test but testing is probably the most important part of quality software dev and DI + ApplicationContext makes things so much easier. We use Typhoon framework but even rolling your own and adopting the DI + ApplicationContext pattern is very much worth it if you're doing any level of testing.