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.
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:
Then whenever you need your locationService you call
So that when you're testing, you can do something like:
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:
And here is MockThirdPartyService.m:
To use, you would do something like:
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.
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.
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
in your test targets scheme choose the new configuration
And yet another option:
Probably the best: no code needs to be changed.