I am using OCHamcrest and OCMockito for unit testing an iOS project. I'm working my way toward understanding using custom matchers in a mock verification of a method expectation that takes parameters. In particular, I want to verify one of the parameters passed to the expected method, but I need to pull apart the passed parameter in order to do so. To demonstrate, here's what I have for the relevant part of my test method:
EAAccessory *accessory = mock([EAAccessory class]);
UIViewController <ZKSearchManagerDelegate> *mockController =
mockObjectAndProtocol(
[UIViewController class], #protocol(ZKSearchManagerDelegate)
);
[verify(mockController)
zkZSensorFound:isSensorWithAccessory(accessory)
fromSearchManager:_sm];
The -zkZSensorFound:fromSearchManager: takes an object that contains an EAAccessory as a property. In my custom matcher, I need to open up that object and examine that property to make sure it's the same object as accessory within this test method. It's easy enough to pass accessory into the matcher as I'm doing here, but how do I get at the actual object that is passed to the parameter for use inside of my matcher? Or, am I going about this all wrong?
Update
I've accepted the answer from #JonReid, as it's a much more elegant solution than what I've concocted. Nevertheless, I think what I was using (thanks to this blog post), could be useful elsewhere:
#import "ArgumentCaptor.h"
EAAccessory *accessory = mock([EAAccessory class]);
UIViewController <ZKSearchManagerDelegate> *mockController =
mockObjectAndProtocol(
[UIViewController class], #protocol(ZKSearchManagerDelegate)
);
ArgumentCaptor *captor = argCaptor();
[verify(_mockController) zkZSensorFound:(ZKZSensor *)captor
fromSearchManager:is(sameInstance(_sm))];
ZKZSensor *sensor = captor.argument;
assertThat(sensor.accessory, is(_mockAccessory));
First, be aware that when you don't specify a matcher to OCMockito, it uses the isEqual matcher. This probably isn't what you want to verify for the second argument. I'd check for identity instead:
fromSearchManager:sameInstance(_sm)
If the argument is typed, it will complain that the matcher sameInstance isn't a search manager. The workaround is to cast the matcher to remove the typing:
fromSearchManager:(id)sameInstance(_sm)
Now for the first argument: you may not need to make a custom matcher at all. If all you want to do is check a property value, use hasProperty. Assuming the property is named accessory,
zkZSensorFound:(id)hasProperty(#"accessory", sameInstance(accessory))
Putting it all together:
[verify(mockController)
zkZSensorFound:(id)hasProperty(#"accessory", sameInstance(accessory))
fromSearchManager:(id)sameInstance(_sm)];
Related
I am trying to write a test case for a method in Objective-C class which returns void. The method mobileTest just creates another object of class AnotherClass and calls a method makeNoise. How to test this ?
I tried to use OCMock to create test this. Created a mock object of AnotherClass, and called mobileTest method. Obviously, the OCMVerify([mockObject makeNoise]) won't work, as I am not setting this object anywhere in the code. So, how to test in such cases ?
#interface Hello
#end
#implementation HelloWorldClass()
-(void)mobileTest{
AnotherClass *anotherClassObject = [AnotherClass alloc] init];
[anotherClassObject makeNoise];
}
#end
#interface AnotherClass
#end
#implementation AnotherClass()
-(void) makeNoise{
NSLog(#"Makes lot of noise");
}
#end
Test case for the above is as follows :
-(void)testMobileTest{
id mockObject = OCMClassMock([AnotherClass class]);
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
There's not a simple answer to this without going a bit into what OCMock is meant for and what test design paradigm it implies.
The short version is: You should not test this like that in the first place. Tests should treat the tested methods as a black box and only compare & verify input vs output.
Longer version: You're trying to test for a side effect, basically, since makeNoise doesn't do anything that the HelloWorldClass even registers (or "sees"). Or to put it in a more positive way: As long as makeNoise is properly tested in the tests written for AnotherClass you don't need to test that simple call.
The example you provide may be a bit confusing, since obviously that doesn't leave anything meaningful to test in mobileTest's unit test, but considering that you might also question why to outsource the simple NSLog call to another class in the first place (and testing for an NSLog call is kind of pointless, of course). Of course I understand you're just using this as an example and envision a more complex different scenario in which you want to ensure that a specific call happens.
In such a situation, you should always ask yourself "Is this the correct place to verify this?" If the answer is "yes" that should imply that whatever message you want to test to be called needs to go to an object that's not completely inside the scope of the tested class only. For example, it could be a singleton (some global logging class) or a property of the class. Then you have a handle, an object that you can properly mock (for example, set the property to a partially mocked object) and verify.
In rare cases that might lead you to provide a handle/property for an object simply to be able to replace it with a mock during testing, but that often indicates a sub-optimal class and/or method design (I'm not gonna claim that's always the case, though).
Let me provide three examples from one of my projects to illustrate something similar to your situation:
Example 1: Verifying that an URL is opened (in mobile Safari): This is basically verifying that openURL: is called on the shared NSApplication instance, something very similar to what you have in mind. Note that the shared instance is not "completely inside the tested methods scope" as it is a singleton"
id mockApp = OCMPartialMock([UIApplication sharedApplication]);
OCMExpect([mockApp openURL:[OCMArg any]]);
// call the method to test that should call openURL:
OCMVerify([mockApp openURL:[OCMArg any]]);
Note that this works due to the specifics of a partial mock: Even though openURL: is not called on the mock, because the mock has a relationship to same instance that is used in the tested method it can still verify the call. If the instance weren't a singleton that would not work, you would not be able to create the mock from the same object that is used in your method.
Example 2: Adapted version of your code to allow "grabbing" the internal object.
#interface HelloWorldClass
#property (nonatomic, strong) AnotherClass *lazyLoadedClass;
#end
#implementation HelloWorldClass()
// ...
// overridden getter
-(AnotherClass *)lazyLoadedClass {
if (!_lazyLoadedClass) {
_lazyLoadedClass = [[AnotherClass alloc] init];
}
return _lazyLoadedClass;
}
-(void)mobileTest{
[self.lazyLoadedClass makeNoise];
}
#end
And now the test:
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockObject = OCMPartialMock([helloWorldObject lazyLoadedClass]);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
The lazyLoadedClass method might even be in a class extension, i.e. "private". In that case, just copy the according category definition to the top of your test file (I usually do this, and yes, this is, IMO, a valid case of basically "testing private methods"). This approach makes sense if AnotherClass is more complex and requires elaborate setup or something. Usually stuff like this then leads to the scenario you have in the first place, i.e. its complexity makes it to more than just a helper than can be thrown away after the method finishes. this will then also lead you to better code structure, since you have its initializer in a separate method and can test that accordingly, too.
Example 3: If AnotherClass has a non-standard initializer (like a singleton, or it comes from a factory class) you can stub that and return a mocked object (this is kind of a brain-knot, but I have used it)
#implementation AnotherClass()
// ...
-(AnotherClass *)crazyInitializer { // this is in addition to the normal one...
return [[AnotherClass alloc] init];
}
#end
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockForStubbingClassMethod = OCMClassMock([AnotherClass class]);
AnotherClass *baseForPartialMock = [[AnotherClass alloc] init];
// maybe do something with it for test settup
id mockObject = OCMPartialMock(baseForPartialMock);
OCMStub([mockForStubbingClassMethod crazyInitializer]).andReturn(mockObject);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
This looks kind of stupid and I admit it's plain ugly, but I have used this in some tests (you know that point in a project...). Here I tried to make it easier to read and used two mocks, one to stub the class method (i.e. the initializer) and one that then is returned. The mobileTest method should then obviously use the custom initializer of AnotherClass, then it gets the mocked object (like a cuckoo's egg...). This is useful if you want to specially prepare the object (which is why I used a partial mock here). I am actually not sure atm if you could also do this with only one class mock (stub the class method/initializer on it so it returns itself, then expect the method call you want to verify)... as I said, brain-knotting.
I may not completely understand mocking as I have a burning question about a very basic scenario. How does one test an instance method of a class OR how does one test a category method for a class?
Consider a class PeerMessage which defines a few properties, etc. I create my own custom category for PeerMessage called Type where I define a method, isTextMessage:. isTextMessage returns a boolean value based on the contents of a PeerMessage. (Please not that this is just an sample type.)
In a test with OCMock, I configure a mock of type PeerMessage and set it's content to some valid value as follows:
id peerMessage = [OCMockObject mockForClass:[PeerMessage class]];
[[[peerMessage stub] andReturn:#"<valid>"] content];
And then assert that peerMessage is a text message:
XCTAssert([peerMessage isTextMessage]);
Considering how mocking works, this results in: 'Unexpected method invoked'. Clearly, as I didn't specify that I was expecting it; neither did I stub it. As I just wanted to verify this API.
How does one test these instance methods (in this case, category instance methods). One way to do this is to redesign the category as follows:
Instead of
- (BOOL)isTextMessage;
do:
+ (BOOL)isTextMessage:(PeerMessage *)message;
But this is to me is very unnatural and I don't feel like writing this code although I don't see anything wrong with it. It doesn't need to be class method. :/
(If my explanation for the question is a bit ambiguous, I'd be happy to update.)
You want to use a partial mock, somehow like this:
id peerMessage = [OCMockObject partialMockForObject:[[PeerMessage alloc] init]];
[[[peerMessage stub] andReturn:#"<valid>"] content];
XCTAssert([peerMessage isTextMessage]);
This way, the real implementation of isTextMessage, the one you want to test, is invoked, but you can still stub out other methods on the object.
I try to dynamically call certain viewController/Feature depends on his Name.NSClassFromString
(that kind of idea was suggested by Facebook).
For Instance from my server I can define in IOS app which feature or viewController should be used.(or On/Off them)
I searched all over Stack but still cant find an elegant way to implement what I want
Class myclass = NSClassFromString(className);
id obj = [[myclass alloc] init];
will work.
But I would like to call my custom init.
Class myclass = NSClassFromString(className);
id obj = [[myclass alloc] initWithCostumInitializer:userInfo];
I cant find a proper way to do it. Of course every time I receive an error because initWithCostumInitializer is not recognised.So I need to make the decision in run time.I believe I missing something.
Tnx a lot.
First off, you shouldn't get a compile-time error about an unknown method if the headers for the possible classe(s) are imported into the .m file where this code is running. Because of exactly this sort of dynamism, ObjC should let you get away with calling fairly arbitrary methods on objects of type id.
But that's just a bandaid solution. Really, if you know that that custom initializer method is present, then it's not an arbitrary class, right? You have some idea what kind of object it is, or at least what kind of base class it derives from, otherwise you wouldn't know to call that method. So you could always:
id customObj = [((BaseViewController *)[myclass alloc]) initWithCustumInitializer:userInfo];
If your error is a runtime error about the receiver missing that selector, then you have a real problem, which is: why are you calling a named method on an object that might not be the kind of object that has that method? If that's what's happening, you'll need to look at the class first to figure out what kind of thing you're actually about to create, and then behave appropriately for the init.
I am writing a class that will return an NSPredicate. I have written code like this:
constructedPredicate = [self predicateForSection:self.systemsSection];
I am wanting to keep the logic central to one method (other parts of the class call this same method and pass different properties), but my intuition is that it is a code smell / bad practice to call a method and pass a property into it. Is there a better pattern?
Nah; that is fine.
The property is a simple accessor. It just grabs the current state from the object.
The method computes a value based on a parameter.
This is exactly the delineation in functionality that properties were designed to address.
No, I don't see anything wrong with that at all.
Which from the following is the correct way of obtaining the meta class?
Class myMetaClass = objc_getMetaClass("NSString");
Or:
Class myMetaClass = object_getClass([NSString class]);
Are they both any different?
As mentioned in another post that is linked by the first answerer here:
Please tell me why objc_getMetaClass(); would break in certain cases in detail.
The proper way to use those in different scenarios.
Both functions are correct, but objc_getMetaClass("NSString") only works if NSString is registered with the objective C runtime. Which it almost always is if you want to get its metaclass.
But if you're creating a class using Class myClass = objc_allocateClassPair(superClass,"my_own_class",0) the situation is slightly different.
my_own_class isn't registered yet, so if you need to access the metaclass (in order to add class methods), you must use object_getClass(myClass).
objc_getMetaClass("my_own_class") would return nil.
The difference is, that the second function returns the object for the named class and the second first the object for the metaclass of the named class... :)
Both of them call the class handler callback if the class is not registered to check a second time. When you call the metaclass function you WILL get a return result.
...(However, every class definition must have a valid metaclass
definition, and so the metaclass definition is always returned,
whether it’s valid or not.)
from: Objective-C Runtime Reference
I think your real question is: What is the difference between a class and a metaclass ?
Please have a look at this excellent explanation:
What is meta-class in objective-c